VMware ESXi and vSphere Cluster Management

Create and Manage Reports in Splunk

Learn how to validate a Splunk search, save it as a report, configure output and time ranges, share it, schedule it, add it to dashboards, and edit it later.

A Splunk report is a saved search intended for repeated use, sharing, scheduling, or display in a dashboard. Saving a search preserves its search logic and, when applicable, its output and visualization choices.

An ad hoc search is a search you run for an immediate question. A saved search is a stored search definition. A report is a common saved-search use case: it can be rerun with defined time behavior, shared with other users, scheduled, and embedded in dashboards.

Prepare and Validate the Search

Before saving a report, run the search in the Search app. Validate both the SPL and the result. Confirm that the search returns the intended events, statistical table, chart, single value, or other visualization.

1. Choose the index, sourcetype, fields, and filters needed for the question.
2. Select an appropriate time range.
3. Run the search and inspect representative results.
4. Check field names, event counts, grouping fields, sort order, and calculated values.
5. Switch between available result views when appropriate to confirm that the output supports the report you want to create.

A transforming search converts events into aggregated or structured output. Common transforming commands include stats, chart, timechart, and table. For example:

index=auth action=failure earliest=-24h
| stats count as failures by user, src_ip
| sort - failures

This search produces a table of authentication failures grouped by user and source address. The exact index, field names, and filter values depend on the data available in your Splunk deployment.

index=web status=200 earliest=-7d
| timechart span=1d count as requests

This search produces a time-based series that can be displayed as a chart. A non-transforming event search behaves differently: it primarily returns matching events, so its presentation options are not the same as those of a search that produces statistics or chart data.

Save the Current Search as a Report

1. Run and validate the search in the Search app.
2. Open the search results page's save menu.
3. Select the option to save the current search as a report. The exact label can vary by Splunk version.
4. Complete the report save dialog.
5. Review the post-creation actions and select any that are needed.

The save dialog creates a report definition from the current search. It uses the current search logic and the configuration you provide for identification, content, and time behavior.

Report identification fields

Give the report a title that explains what it measures. Add an optional description describing its purpose, data scope, owner, intended audience, or operational use.

Useful naming conventions include a consistent purpose, subject, and frequency, such as Security - Failed Logins - Daily or Web - Request Volume by Day. For an incident snapshot, include the incident identifier or date in the title. Avoid vague names such as “Test Search” or duplicate names that make the object difficult to identify.

Choose Report Content and Presentation

For a transforming search, choose whether the report should retain or display tabular output, visualization output, or both when those choices are available. A table is useful for detailed values and investigation. A visualization is useful for trends, comparisons, and monitoring.

For example, the failed-login report can retain its table and optionally show a column chart. The web traffic report can emphasize its timechart visualization. If the original search returns raw events rather than transformed results, chart and statistical display choices may not be available or meaningful until the SPL is changed.

Presentation settings do not replace search validation. A report can have a valid visualization configuration but still produce misleading results if the fields, filters, or time range are incorrect.

Configure Time Range Behavior

A time range picker is a report control that lets a user choose the period used when running the report. Decide whether the report should expose this control.

• Relative time range: Defines a window relative to execution time, such as the last 24 hours or the last seven days. This is appropriate for recurring operational reports because the same report automatically follows the current period.
• Fixed time range: Uses predefined start and end times. This is appropriate for a historical snapshot, such as an incident investigation tied to a specific period.
• User-selectable time range: Keeps the time range picker available so viewers can inspect different periods without editing the report.

If the time range picker is omitted or disabled, users cannot interactively replace the report's defined time range through that control. The report therefore uses its saved fixed or relative range. Verify this behavior before sharing the report.

Actions After Creating a Report

After creation, review the confirmation page or available report actions. The options shown depend on your Splunk version, app context, role, and permissions.

Example: daily failed-login summary

Save the validated statistical search as Security - Failed Logins - Daily. Use a relative last-24-hours range, retain the table, and optionally add a column chart. If the security process requires an automatic review, configure a daily schedule. Limit access to the security audience when the underlying data is sensitive.

Example: weekly web traffic trend

Save the timechart search as Web - Request Volume by Day. Use a visualization-oriented content choice, keep the time picker available so viewers can inspect different periods, and add the report to a dashboard.

Example: incident investigation snapshot

Save the filtered search with a title containing the incident context. Describe the data source and analytical purpose. Use a fixed historical time range when the report must remain tied to the investigated period, and restrict permissions to the incident response team.

Find and Edit Existing Reports

Manage existing reports from Settings, then the area for searches, reports, and alerts. Reports are knowledge objects, so their ownership, permissions, and app context affect how they appear.

1. Open the searches, reports, and alerts management area.
2. Choose the relevant app context.
3. Locate the report by title, owner, or other available filters.
4. Open the report's edit controls.
5. Change the search, title, description, time settings, schedule, permissions, or display settings as needed.
6. Run the changed search and inspect its event or transformed output.
7. Check dashboard panels and scheduled behavior if the report is used by either.

Always test changes after editing. A field rename, index change, altered time range, or modified SPL command can affect result accuracy, visualizations, dashboards, and scheduled workload.

Sharing and Access Control

Sharing controls determine who can discover, run, edit, or embed a report. Common scopes include:

• Private: Available only to the owner and authorized administrators or users with appropriate capability.
• App-level: Available within a particular app to users whose roles allow access to the app and object.
• Broader sharing: Available across a wider scope when the deployment's permissions model supports it.

The exact choices depend on the Splunk deployment. App context matters: a report saved in one app may not appear when browsing another app. User roles also matter; a person may be able to run a report without being allowed to edit its definition, or may be unable to see it at all.

Sharing a report does not automatically provide access to its underlying index, source data, fields, or data models. Verify that intended viewers can search the required data and that the report does not expose information beyond their authorization.

Report Lifecycle and Maintenance

• Document the report's purpose, owner, data scope, intended audience, and expected time behavior.
• Review reports when indexes, sourcetypes, fields, data models, or business requirements change.
• Search for existing reports before creating another one to avoid duplicates.
• Retire obsolete saved searches and reports after confirming that no dashboard, schedule, or process depends on them.
• Monitor scheduled reports for failures, skipped executions, long runtimes, and excessive resource use.
• Reassess acceleration when data volume, SPL, schedule, or reporting requirements change.

Troubleshooting

The report cannot be found after saving

Check the searches, reports, and alerts settings page, the app context, the report title, and the owner. It may be private or stored in a different app. Your current role may also limit which knowledge objects you can see.

Other users cannot view or run the report

Review whether the report remains private, whether its sharing scope matches the intended audience, and whether role permissions allow access. Also verify that viewers can search the underlying index and data.

The report shows an unexpected period

Inspect the saved time configuration. A fixed range may have been saved unintentionally, the time range picker may be disabled, or a relative range may be moving forward each time the report runs. Edit the report so its behavior is fixed, relative, or user-selectable as intended.

A chart or table is missing

Validate the search output and confirm that it is a transforming search when a chart or statistical table is expected. Review the saved content choice and visualization settings, then edit and test the report again.

A scheduled report is slow or does not complete

Check whether the time window is too broad, the SPL is inefficient, or the schedule overlaps other resource-intensive searches. Optimize the search and narrow the range where appropriate. Evaluate report acceleration only if the report type is eligible and the performance benefit justifies its resource cost.

For the complete workflow on this page, start with creating a Splunk report, then validate its permissions, time behavior, presentation, and maintenance requirements.