Understanding the Challenge
Skipped acceleration searches are common in Splunk Cloud. These background jobs maintain summary data for reports and data models. When they fail, dashboards may show gaps or stale results. However, the underlying reason is not always easy to uncover. Accelerated reports and data models run as hidden system jobs rather than standard saved searches. Because of this, Splunk administrators often see the failure but not the origin. Consequently, investigating skipped accelerations requires a different approach.
The Limits of Visibility
Splunk Cloud hides acceleration jobs with names beginning _ACCELERATE_. These jobs never appear in /services/saved/searches. Therefore, REST API queries cannot directly match them to a parent report. Although data model accelerations are easier to identify by name, they also need context to understand their relevance. This limited visibility makes automatic correlation impossible. Administrators must instead rely on metadata such as the app and owner of the skipped job. Manual correlation provides enough context to decide what should remain accelerated.
Finding the Skipped Jobs
The _internal index stores scheduler information about skipped searches. Administrators can use it to detect failing accelerations.
A reliable search is shown below:
index=_internal sourcetype=scheduler savedsearch_name="_ACCELERATE*"
status=skipped search_type="*_acceleration"
| stats count AS skipped_searches BY savedsearch_name reason user app search_type
This SPL lists all skipped accelerations, including both reports and data models. Each entry contains the app, user, and reason for skipping. Using these details, one can group failures by owner or application and then decide where to focus the review.
Manual Correlation for Accelerated Reports
Correlating accelerated reports requires human verification. After identifying skipped accelerations, administrators should open Settings > Searches > reports > alerts. Filtering by app and owner reveals candidate reports. At this point, each report with Acceleration: Enabled should be reviewed. Reports must be checked for usefulness, frequency, and actual data returned. If a report returns no results or is no longer used, its acceleration can be disabled. Conversely, reports critical to operations should remain accelerated but may need schedule adjustments. Sometimes vendor-supplied apps enable acceleration by default. These automatic settings should be validated to confirm their necessity.
Evaluating Accelerated Reports
Every accelerated report deserves a short audit. Administrators should verify that each job still supports a dashboard, workflow, or business process. When a report produces empty or obsolete results, its acceleration likely wastes resources. In that case, disabling it prevents unnecessary scheduler load. If the acceleration schedule conflicts with others, changing the cron timing can reduce contention. Similarly, narrowing the acceleration time range often minimizes skipped runs. Through careful observation, the overall scheduler health improves and search concurrency stabilizes.
Investigating Data Model Accelerations
Data models follow the same principle but are easier to identify. The job name includes the model title, such as DA-ES-IdentityManagement_Acceleration. After locating skipped DMA jobs, administrators can open Settings → Data models. Filtering by app exposes the corresponding model. Each model must then be checked for two things: whether it holds data and whether it is in use. Models used in Splunk Enterprise Security or CIM compliance are normally essential. Others may belong to third-party applications and serve no purpose. As a result, disabling unused models can recover system capacity without affecting business needs.
Assessing Data Model Relevance
A data model might appear active but remain empty. Therefore, administrators should run:
| datamodel <name> search
If no data is returned, the model may not receive events. On the other hand, if the model powers dashboards or correlation searches, acceleration should continue. Reviewing summary ranges and reducing unnecessary datasets helps optimize storage and performance. Ultimately, each decision depends on whether the data model aligns with business objectives and user requirements.
Making Case-by-Case Decisions
Not all accelerations serve the same purpose. Each skipped job tells part of the story, but context completes it. Some accelerated reports are user experiments left running long after their relevance ends. Others are vital for executive dashboards that must stay responsive. Likewise, some applications ship accelerated content that no one monitors. Because of these variations, every evaluation must be handled individually. Collaboration with report owners ensures that no critical analytics are lost during cleanup.
Streamlining the Review Process
A repeatable triage workflow helps maintain long-term stability. The sequence below summarizes the approach:
- Run the _internal query to identify skipped accelerations.
- Group results by app and user.
- Check the reports menu for accelerated searches.
- Confirm relevance and data availability.
- Evaluate schedules and adjust if needed.
- Perform the same review for data models.
- Document actions and revisit regularly.
Although these steps require manual effort, they create transparency across applications and users. As schedules improve, skipped searches decrease significantly.
Key Takeaway
Monitoring skipped accelerations protects Splunk Cloud performance. Because the system hides _ACCELERATE_* jobs, a manual but structured review becomes necessary. Combining scheduler data with human evaluation offers the most reliable triage method. By routinely examining accelerated reports and data models, organizations ensure resources serve active business needs rather than unused processes. Consequently, both search performance and data relevance improve over time.
To access more Splunk searches, check out Atlas Search Library, which is part of the Atlas Platform. Specifically, Atlas Search Library offers a curated list of optimized searches. These searches empower Splunk users without requiring SPL knowledge. Furthermore, you can create, customize, and maintain your own search library. By doing so, you ensure your users get the most from using Splunk.
