Investigating Past Events with Pulse Explorer

Investigating Past Events with Pulse Explorer

Pulse gives TM1 administrators the ability to investigate past performance events with real data, moving from user complaints to factual explanations quickly.

Example 1: "The Application is Slowing Down"

Is the user really waiting?

Go to User Sessions and check the Waiting % for the user. Pulse tracks every session, showing what percentage of time a user spent waiting. A low waiting percentage (e.g. less than 1%) may indicate the complaint is not reflective of a systemic issue.

Check individual sessions

Click on the user to view session-level detail. This shows wait time per session, including the time of day. For example, a single session at 1:56 AM showing 93% wait time points to a maintenance chore running during that window — not an application performance problem.

Report back to the user

With this data you can give the user a factual explanation: they were waiting because they accessed the system during the maintenance window when nightly chores were running.

Example 2: "This Process Took a Long Time a Few Days Ago"

Check min/avg/max run times

In the Chore / Process History, find the affected process and review its Min, Avg, and Max run times. A large gap between minimum and maximum (e.g. 0.5 sec vs 4,000 sec) confirms an anomaly occurred.

Use the Explorer to find the timestamp

Open the Chore/Process History dashboard in Pulse Explorer and filter by the process name:

Name: *ProcessName

The chart will show when the maximum run time occurred, giving you an exact timestamp.

Identify the blocking thread

Open the Active Thread dashboard in Pulse Explorer and filter to the exact timestamp of the anomaly. This shows all threads running at that moment, revealing which process was locking the affected one.

In the example above, a view/subset cleanup process was running at that time and locking the target process.

Key Takeaway

Pulse makes TM1 environments observable — you can answer almost any question about past system behaviour with real data. This capability helps administrators diagnose issues confidently and communicate factually with users who report problems.