Optimizing Splunk Dashboards with the tstats Command

The Performance Gap: Raw Search vs. tstats

When a Splunk dashboard slows down as data volume grows, the cause is usually the cost of scanning raw events. A standard search reads every matching event from disk, extracts fields at search time, and then aggregates them. For high-frequency dashboards and scheduled reports, that is expensive.

The | tstats command avoids this by reading statistics straight from the TSIDX files, the index files Splunk builds for indexed fields and accelerated data model summaries, instead of from raw events. For aggregate questions, it is typically far faster than the equivalent raw search.

Querying Indexed Fields

Against a standard index, tstats only sees fields that exist at index time: default metadata such as index, host, source, and sourcetype, plus any fields you have explicitly configured as indexed. Fields created by rex, eval, lookups, or search-time extractions are invisible to it.

Example: hourly request volume.

| tstats count WHERE index=web sourcetype=access_combined by _time span=1h

• Where to run: the Splunk Search bar on your search head.
• Permissions: read access to the web index.
• Placeholders: replace web and access_combined with your own index and sourcetype.
• Expected check: a two-column table of hourly _time buckets and count values.

Querying Accelerated Data Models

For richer fields such as user or dest_ip, use an accelerated data model. Acceleration builds a summary of the model's fields, which tstats queries through the from clause.

Example: action distribution from the Web model.

| tstats count from datamodel=Web.Web by Web.action

Here Web is the data model name and Web.action is a field mapped inside it. This is the primary engineering path for migrating slow, high-traffic dashboards: move the aggregate panels to tstats over an accelerated model, and reserve raw-event searches for ad hoc investigation and detail drilldowns.

You can also pair tstats with prestats=true followed by stats, chart, or timechart, so dashboards reuse the accelerated summary while still formatting results like a normal transforming search.

Limitations and Common Pitfalls

The most common reason a tstats search returns zero results, while the equivalent raw search returns thousands, is field visibility.

Search-time fields are invisible

Teams often assume a field exists because it appears in a normal search. If it comes from a search-time extraction, a calculated field, or a lookup, tstats cannot see it. It only reads index-time fields and fields mapped in an accelerated data model.

Acceleration must be built and in range

Before tstats against a data model returns anything, acceleration must be enabled and the summary built. Summaries are built incrementally and cover a configurable time range, so queries outside that range can return incomplete results. The summariesonly argument controls whether tstats falls back to raw events for uncovered ranges, and its default behavior varies by Splunk version, so confirm it against your installed release's documentation before relying on it.

Acceleration is not free

Building summaries consumes disk space and indexer CPU. Enabling acceleration broadly on large data models, without scoping the time range, can be expensive.

Verifying the Result

Compare a raw search and its tstats equivalent side by side in the Splunk job inspector:

1. Run the raw baseline: index=web sourcetype=access_combined | timechart span=1h count.
2. Run the tstats version: | tstats count WHERE index=web sourcetype=access_combined by _time span=1h.
3. Open the job inspector for both jobs and compare the number of events scanned. The tstats job should scan far fewer events, because it reads index metadata rather than raw buckets.

Before trusting results against a data model, check Settings > Data Models: confirm acceleration is enabled and review the summary size and last update time. If a tstats search returns nothing, test the WHERE clause against a known indexed field such as index or sourcetype first, to isolate whether empty results come from field visibility or from syntax.

Rollback and Resource Management

tstats itself is read-only and needs no rollback. Data model acceleration does change indexer state: it writes summary files and consumes CPU while building them. If indexer CPU or disk usage spikes after enabling acceleration, disable it under Settings > Data Models by selecting the model and choosing Edit > Disable Acceleration.

Decision Matrix: When to Use tstats

Requirement	Standard search	tstats
Ad hoc investigation of raw logs	Recommended	Not possible
High-level dashboard aggregates	Slow and expensive	Recommended
Fields from lookups or calculated fields	Supported	Only via an accelerated data model that maps them
Aggregating very large event volumes	Inefficient	Recommended