A base search is a single query in a Splunk dashboard that retrieves data once, then feeds its results to multiple smaller queries called post-process searches. Instead of each panel on your dashboard running its own full search against your indexes, one base search does the heavy lifting, and the post-process searches filter, reshape, or summarize those results for individual visualizations.
How a Base Search Works
Think of a base search as a shared data source for your dashboard. It runs one query against your indexes and holds the results. Post-process searches then take those results and do additional work on them, like aggregating by a different field or filtering to a subset of events. The key point: the expensive part of searching (pulling data from disk and processing it) only happens once.
Here’s a concrete example. Say your base search pulls internal log data and counts events by component and log level. A first post-process search might take those results and sum the counts by log level alone, while a second post-process search summarizes by component. Both panels share the same underlying data without querying the index twice. You can chain multiple post-process searches together or use them individually, depending on what each panel needs to display.
Performance Benefits
When used properly, base searches improve dashboard performance because you do the hard work of going through the index once and reuse the results several times. If your dashboard has five panels that all need data from the same index and time range, converting them from five independent searches to one base search with five post-process searches can significantly reduce load on your Splunk environment.
On heavily used dashboards, this also reduces your concurrent search load. Splunk enforces concurrency limits on how many searches can run simultaneously, so fewer total searches means less queuing and faster load times for everyone. This matters most in shared environments where many users open dashboards throughout the day.
The 500,000 Event Limit
Base searches have an important constraint. If the base search is a non-transforming search (meaning it doesn’t aggregate results with commands like stats or chart), Splunk retains only the first 500,000 events it returns. Any post-process search silently ignores events beyond that limit, which can produce incomplete or inaccurate results without any warning. This limit is controlled by the max_count setting in limits.conf and defaults to 500,000.
This is why base searches that are too broad can actually hurt more than they help. A base search returning millions of raw events will hit the cap, consume a large amount of disk space for search artifacts, and eat into the user’s disk quota. That disk usage can cause queuing for other search jobs until the artifacts are cleaned up.
When to Use a Base Search
Base searches work best when your dashboard panels share a common data source but need to slice it differently. A good pattern is a base search that retrieves login events counted by user and workstation, with one post-process search creating a table of stats by user and another showing stats by workstation. The base search does the index scan once, and each panel just reshapes the same result set.
A poor pattern is making the base search overly generic, returning a huge volume of raw, non-aggregated events in hopes that post-process searches will do all the filtering. This leads to hitting the 500,000 event cap, slow performance, and large disk consumption. The base search should be specific enough to return a focused dataset but broad enough that multiple panels can derive what they need from it. Including a transforming command like stats in the base search itself keeps the result set compact and avoids the event limit entirely, since transforming searches produce summary rows rather than raw events.
Base Search vs. Inline Search
The alternative to a base search is an inline search, where each panel runs its own independent query. Inline searches are simpler to set up since each visualization is self-contained. You don’t need to think about how one panel’s query relates to another. But they’re less efficient when multiple panels pull from the same data, because each one triggers a separate search job.
Use inline searches when panels need completely unrelated data. Use a base search when two or more panels query the same index, source, or time range and differ only in how they aggregate or filter the results. Dashboards that exceed concurrency limits or have long load times are often good candidates for converting inline searches into a base search with post-process searches. Also note that dashboards exceeding roughly 7,000 characters in their URI can fail to load consistently, so consolidating searches can help keep dashboard definitions leaner.