Pulse Explorer – Complete Guide: Concepts, Performance & Custom Reporting

This guide answers the most common questions about Pulse Explorer — the OpenSearch Dashboards-powered analytics layer built into Pulse. It covers core concepts, best practices for large environments, performance investigation techniques, and how to build your own custom dashboards and reports.

Part 1 – Core Concepts & Daily Use

Pulse vs Pulse Explorer – What's the Difference?

Pulse is the overall monitoring and management platform for IBM Planning Analytics (TM1). It tracks changes, manages migrations, provides live monitoring, sends alerts, and stores all activity second-by-second into an embedded OpenSearch cluster.

Pulse Explorer is the visualization and analytics layer on top of that OpenSearch cluster. It is powered by OpenSearch Dashboards (the open-source successor to Kibana) and lets you ask open-ended, historical questions about your TM1 environment — far beyond what real-time monitoring alone can answer.

Think of Pulse (core) as your real-time cockpit and Pulse Explorer as your flight recorder and analytics engine.

Pulse Explorer is only accessible to Pulse Admins. Click the Explorer button in the Overview section to open it.

Best Practices for Large Environments with Many Instances

When monitoring many TM1 instances across multiple servers, the volume of data stored in OpenSearch can grow quickly. Follow these practices to keep Pulse Explorer fast and useful:

Data storage & retention

• Tune index frequency per index using the *IndexPattern settings in Pulse.cfg. For example, switch pulse-server-state from monthly (yyyy-MM) to daily (yyyy-MM-dd) if you want finer control over how much data is retained: Understanding Pulse Opensearch dataPreview

Filtering in Explorer

• Always start by filtering on a specific instance name or server before exploring a dashboard. This dramatically reduces the number of documents scanned.

• Use the date picker to constrain your time window as tightly as possible. Querying 7 days instead of 30 days can reduce query time by 4×.

• Save frequent filter combinations as pinned filters in a dashboard so colleagues don't have to rebuild them each time.

Index awareness

• High-frequency indices like pulse-tm1-top (created daily) grow fastest. If you don't need minute-by-minute thread tracking, note that this index is disabled by default — keep it that way unless you specifically need it.

• Monthly indices like pulse-server-state are good for trending memory and CPU over weeks.

• Yearly indices like pulse-chore-process-history are ideal for long-term process performance baselines.

Integrating Pulse Explorer into Daily Development Work

Pulse Explorer is most valuable when it becomes part of your regular development habits rather than a tool you only open when something breaks.

Start of day check

Open the Pulse – Live Monitor dashboard and set the time window to the last 24 hours. This immediately shows you if any overnight chores ran longer than usual or failed. Something to watch closely is the WaitTime.

Other important dashboards:

• Pulse - Chore / Process History: Analyzing Chore/Process History

• Pulse - Error Analysis: Quickly see errors in your applications

• Pulse - User License Report: See how is using your applications and which tool they are using.

After deploying changes

Use the pulse-tm1-object-history index (DocumentType: CubeStats) in Discover to check whether cube sizes — feeders, populated cells, RAM — changed after a code deployment. Compare before and after snapshots to catch unexpected feeder explosions early. To capture this information, Performance Monitor needs to be on:Why Pulse Turns On Performance Monitor in TM1Preview

Part 2 – Performance & Optimization

Finding Detailed Cube Statistics (Feeders, File Size, RAM)

Pulse documents cube statistics every time the documentation runs (by default daily at 1:30 am). These are stored in the pulse-tm1-object-history index under DocumentType CubeStats.

Via Model Spotlight (recommended starting point)

1. Go to Model Spotlight and select your TM1 instance.

2. Choose a cube from the picklist on the right.

3. In the Overview and Performance Statistic section, you will see:

   • Numbers — count of numeric cells

   • Cells Fed — how many cells are fed by rules

   • Memory history chart — memory usage by day

   • Cube Statistics table — historical snapshots of feeder counts, file sizes, and cell counts

Via Pulse Explorer (for bulk analysis across cubes)

1. Open Pulse Explorer > Discover.

2. Select the index pattern pulse-tm1-object-history-*.

3. Add a filter: DocumentType is CubeStats.

4. Add another filter: InstanceName is <your instance>.

5. Useful fields to add to the table: CubeName, FedCells, PopulatedNumericCells, SizeInMemoryMB, FeederFileSize, RulesFileSize.

This gives you a full list of all cubes with their statistics that you can sort and export.

Identifying "Overfed" Cubes

A cube is considered overfed when the number of fed cells is significantly larger than the number of actually populated (non-zero) numeric cells. As a rule of thumb:

If Cells Fed > 2× Numbers (populated numeric cells), investigate for potential overfeeding.

How to find overfed cubes:

In Model Spotlight, look at the Performance Statistic section for each cube. If Cells Fed is more than twice the Numbers value, the cube likely has overly broad feeder statements.

In Pulse Explorer, sort the CubeStats data descending by FedCells and compare against PopulatedNumericCells for a side-by-side ranking of all cubes.

How to find overfed with TM1

The following article will explain how to troubleshoot feeders in a fun way: https://code.cubewise.com/blog/troubleshooting-feeders-in-tm1-with-emojis/

Monitoring Cube Memory Consumption Over Time

The pulse-server-state index (DocumentType: ServiceState) records instance-level memory snapshots every few seconds. For cube-level memory, use the CubeStats DocumentType within pulse-tm1-object-history.

Instance memory trending:

Open the Pulse – TM1 Instances Stats dashboard in Pulse Explorer. Set a broad date range (e.g. last 7 days) to see whether memory is trending upward over time, which can indicate a feeder or data growth problem.

Identifying memory peaks:

The Memory History by Day chart in Model Spotlight (per cube) lets you visually spot days where memory spiked. Cross-reference those dates with Change Tracking to identify what code was modified.

Using the Discover view for precise analysis:

In pulse-server-state with filter DocumentType: ServiceState, add fields such as InstanceName, Memory, MemoryUsed, Timestamp. Sort descending by MemoryUsed to find the historical peak and the exact time it occurred.

Analyzing Peak Usage During Critical Periods

Critical periods — month-end closes, overnight batch runs, or budget cycles — can be reconstructed fully using Pulse Explorer because all thread and session data is stored.

Step-by-step peak analysis:

1. Open Pulse Explorer and navigate to the Pulse - Active Threads dashboard.

2. Set the date picker to the exact critical period (e.g. "Oct 31, 23:00 – Nov 1, 02:00").

3. Filter by InstanceName to focus on the relevant server.

4. Look at the ThreadsWait and ThreadsRun counts over time to find the precise moment of peak contention.

5. Drill into the pulse-tm1-top index (if enabled) via Discover to see the individual threads: which users were waiting, what functions were executing, and which objects were locked.

Searching and Analyzing Historical Process Logs and System Messages

All TM1 server log messages (tm1server.log) are indexed into pulse-tm1-server-log (DocumentType: tm1serverlog).

Open the Pulse - Chore / Process History should be more than enough to see what happened, if you want follow the steps below to create your own query:

Quick search:

1. In Pulse Explorer > Discover, select pulse-tm1-server-log-*.

2. Use the search bar to enter a keyword (e.g. reconciliation failed or ERROR).

3. Set the date range to the period of interest.

4. Add a filter on InstanceName to narrow results to a specific server.

Useful fields to display in the table:

• MessageLevel — INFO, WARN, ERROR, FATAL

• MessageText — the full log message

• InstanceName — which TM1 instance generated it

• Timestamp — when it occurred

Finding all errors from a specific night:

Set the date picker to the overnight window, add a filter MessageLevel: ERROR, and sort by Timestamp. This gives you a chronological list of every error across all monitored instances for that period — far faster than searching individual log files on disk.

Chore/Process log correlation:

Cross-reference pulse-tm1-server-log entries with pulse-chore-process-history (DocumentType: choreandprocesshistory) at the same timestamp to correlate which chore or process was running when an error occurred.

Gaining Insights into Cube Performance, Rule Efficiency, and TI Process Effectiveness

Cube rule efficiency

The pulse-tm1-object-history index (DocumentType: Cube) stores rule metadata including the number of rule lines, rule complexity indicators, and whether rules are active. Use this in combination with CubeStats to correlate cube size with rule complexity.

In Model Spotlight, the Cube Statistics table shows historical changes to feeder counts — a sudden jump in feeders after a documentation date is a reliable signal that a rule change caused excessive feeding.

TI Process effectiveness

The pulse-chore-process-history index is your primary tool here. Open the Pulse – Chore / Process History dashboard and examine:

• Min / Avg / Max execution times for each process across a date range.

• The trend chart per process to spot processes that are gradually getting slower over time (indicating data growth or inefficiency).

• Outliers: filter on a specific process by clicking + and look at the execution time chart to find the date when the "max" occurred, then cross-reference with change tracking.

Identifying long-running processes by instance:

In Discover with pulse-chore-process-history, filter by InstanceName and sort by Duration descending. Add a filter to show only the last 30 days. This gives you a ranked list of the most time-consuming process executions across your entire environment.

Session efficiency:

The pulse-tm1-session-history index (DocumentType: Session) lets you analyze average session duration, peak concurrent user counts, and how long users are spending in wait state — all useful for capacity planning.

Part 3 – Customization & Reporting

Creating Custom Reports and Personalized Dashboards

Pulse Explorer is built on OpenSearch Dashboards, which provides a full self-service dashboard builder. You do not need to modify any Pulse files — everything is done within the Explorer UI.

Creating a new dashboard from scratch:

1. Open Pulse Explorer and click the hamburger menu on the left.

2. Navigate to Dashboard > click Create new dashboard.

3. Click Add to search for and add existing visualizations.

4. To create a new visualization, click Create new and choose a visualization type (see next section).

5. Once you are happy with the layout, click Save and give it a name. Saved dashboards persist across sessions for all Pulse Admin users.

Cloning an existing dashboard:

The easiest way to start is to clone one of the built-in Pulse dashboards:

1. Open the dashboard you want to base yours on.

2. Click Edit in the top right.

3. Use Save As to save a copy with a new name.

4. Modify panels as needed without affecting the original.

Adding filters to a dashboard:

Use the + Add Filter button at the top of any dashboard to add persistent filters (e.g. always show only a specific TM1 instance). These filters apply to all panels simultaneously, making it easy to create instance-specific dashboards.

Sharing dashboards:

Dashboards can be shared via URL using the Share button (top right). Use the Snapshot option for a point-in-time view, or Saved Object link for a live view that always shows current data.

Available Visualization Options

OpenSearch Dashboards (powering Pulse Explorer) offers a rich library of visualization types, all of which can be used with Pulse data:

How to create a new visualization:

1. In the left menu, go to Visualize.

2. Click Create new visualization.

3. Choose a type, then select the index pattern to query (e.g. pulse-chore-process-history-*).

4. Configure the Y-axis (metric: avg, max, count, etc.) and X-axis (time, terms bucket, etc.).

5. Use the Split series bucket to break down results by a field like ProcessName or InstanceName.

6. Click Save to make the visualization available for use in dashboards.

Using Pulse Indices for Custom Reporting

The 10 Pulse OpenSearch indices are the foundation for all custom reporting. Here is a practical guide to the most useful indices and document types for reporting scenarios:

Index pattern reference for custom reports:

Using the DocumentType filter effectively:

Some indices (especially pulse-server-state and pulse-tm1-object-history) contain multiple document types in the same index. Always add a DocumentType filter in your Discover view or visualization before selecting fields — this narrows the available fields to only those relevant to the document type you are working with, making field selection much easier.

Example: Custom "Overnight Batch Performance" report

1. Create a new Data Table visualization.

2. Index: pulse-chore-process-history-*

3. Filter: ProcessName starts with FIN_* (or your prefix) and StartTime between 22:00 and 06:00.

4. Metric: Max of Duration (alias: "Worst Run Time") and Average of Duration (alias: "Avg Run Time").

5. Bucket: Terms on ProcessName, ordered by Max Duration descending.

6. Save and add to a "Batch Operations" dashboard.

Tip – wildcard index patterns:

When querying across multiple years (e.g. for multi-year trend analysis), use the wildcard pattern pulse-chore-process-history-* to span all available yearly indices automatically. OpenSearch will query all matching indices and merge the results transparently.

Quick Reference – Key Links

• Explorer overview page

• Using the Pulse Explorer

• Understanding Pulse OpenSearch data & indices

• Chore / Process History

• Model Spotlight (cube statistics)

• Deleting Pulse OpenSearch indices

• Changing index frequency

• Storing OpenSearch data on another drive

• How to make your TM1 system observable