Splunk Reports Overview

Learn what Splunk reports are, how to create them from searches or pivots, and how to run, schedule, share, embed, and use them in dashboards.

A Splunk report is a reusable saved search or saved pivot. Instead of rebuilding the same SPL search or Pivot analysis, you save its definition and run it whenever you need current or historical results.

Reports are useful for repeatable analysis, operational reviews, security monitoring, business reporting, dashboards, and scheduled workflows. A report can be run manually, scheduled to run automatically, shared with authorized users, or used as the data source for a dashboard panel.

What Is a Splunk Report?

A report is a saved search or saved pivot intended for reuse. A saved search stores an SPL definition, while a saved pivot stores the analysis created through Splunk's data-model-based Pivot interface.

Saving a report preserves its search or pivot definition. When the report runs later, Splunk uses that stored definition rather than requiring you to recreate the search or analysis.

Ad hoc searches, saved reports, and scheduled reports

An ad hoc run is a manual execution of a search or report. It is useful when you need an answer immediately, such as during incident investigation.

A saved report is a reusable knowledge object. It can be opened and run repeatedly, modified, added to dashboards, or shared according to its permissions.

A scheduled report is a saved report configured to run automatically on a recurring schedule. Scheduling changes when the search runs; it does not change the underlying report definition.

Report types by behavior

Ad hoc search: Created and run for an immediate question. It is not necessarily stored for reuse.

Saved report: Stores a search or pivot so users can run it again.

Scheduled report: Runs a saved report automatically at configured intervals and time ranges.

What Reports Can Be Used For

Manual review: Run a report on demand to inspect events, statistics, tables, or visualizations.
Recurring reporting: Schedule a report for daily, hourly, weekly, or other recurring operational, security, or business reviews.
Sharing: Give authorized users or roles read or write access through report permissions.
Dashboards: Use a saved report as the data source for a dashboard panel.
External web content: Use scheduled-report output in external content where the Splunk deployment supports it and authentication, authorization, and exposure controls are configured securely.

Embedding report output is different from exporting a static result. An embedded report can provide refreshed or dynamically retrieved output, while an export or shared file is a copy of results from a particular point in time.

Ways to Create a Splunk Report

Save a search from the Search app: Start with a completed SPL search and save it as a report. This is the usual choice for searches written directly in SPL.

Save a pivot: Start with a data-model-based Pivot analysis and save the pivot as a report. This is useful when analysts work with approved data models instead of writing all SPL manually.

Create from Searches and Reports settings: Enter a search definition and report metadata directly from the management page.

Convert an inline-search dashboard panel: Turn eligible panel logic into a reusable saved report that can be referenced by other dashboards or workflows.

Creating a Report from the Search App

Open the Search app. You can review how to launch the Search app if needed.
Write and run a complete SPL search.
Review the returned events, statistics, table, or visualization.
Use the save action and choose the option to save the search as a report.
Enter a clear report name and, optionally, a description.
Choose the report's time-range behavior when the interface provides that option.
Set initial sharing or permissions as appropriate for your team and app context.
Save the report, then run it again to confirm that the stored definition behaves as expected.

For example, this search counts application errors by service:

index=main sourcetype=application_log level=ERROR | stats count by service

You could save it with a name such as Application Errors by Service and a description explaining the data source, expected time range, and intended audience.

Saving a search is not the same as saving an alert

A saved search is a stored search definition. A report uses that definition to provide reusable results. An alert also uses a saved search, but it adds a trigger condition and an action, such as sending a notification or running a response workflow. Choose the report option when the goal is reusable analysis rather than event-driven notification.

Creating a Report from Pivot

Pivot is a data-model-based analysis interface. It lets users select data-model objects, fields, filters, aggregations, and visualizations through a guided interface.

Pivot is preferable when an organization has approved data models and wants consistent, governed analysis. It can reduce the need for every analyst to know the complete SPL implementation behind a data model.

Open Pivot and select an appropriate data model.
Build the required filters, calculations, tables, or visualizations.
Validate the time range and returned results.
Save the pivot as a report.
Give the report a descriptive name and configure its sharing scope as appropriate.

A saved pivot report can later be found, run, edited, shared, scheduled, or used in a dashboard in much the same way as a saved-search report. Its definition remains based on the Pivot analysis and its associated data model.

Creating a Report from the Management Page

Reports can also be created and managed through the Splunk settings area. The usual navigation path is:

Settings > Searches, Reports, and Alerts > New

From the listing, select the option to create a new report and provide the report metadata and search definition. Depending on the Splunk version, app, and permissions, the form can include:

Report name and description
Search or pivot definition
Time range
Schedule
Owner and app context
Read and write permissions
Dashboard association or related display settings

The management page is also useful for finding existing reports. Where your permissions allow, you can inspect, edit, clone, enable, disable, or delete reports. Cloning is useful when a new report needs similar logic but different metadata, time ranges, permissions, or scheduling.

Converting Dashboard Content into a Report

An inline search is defined directly inside a dashboard panel. The panel contains its own search logic, so the same logic may be duplicated in several dashboards.

A report-backed dashboard panel references a saved report as its underlying data source. The search or pivot definition is maintained as a reusable object rather than being embedded only in one panel.

Open the dashboard in an editor.
Identify an eligible panel that uses an inline search.
Use the panel or editor option to save or convert the inline search into a report.
Give the new report a clear name and configure its permissions and app context.
Verify that the dashboard panel now uses the saved report and produces the expected results.

Reusing one report across multiple dashboards centralizes search logic. A later correction to the report can benefit every authorized consumer, although changes should be tested because they may affect several panels or workflows.

Running Reports

You can run a report on demand from the report listing or from the report's view. A manual run is appropriate when you need current results, want to investigate a historical period, or are testing a report after a change.

When running manually, pay attention to the selected time range. The time range is the period of indexed data searched. A correct search can appear to return no results if the selected period does not contain matching events.

Depending on the report definition, results may appear as raw events, statistics, tables, charts, or other visualizations. Review both the result and the search time range before concluding that the data is absent.

For more background, see the Splunk time range picker and example searches.

Scheduling Reports

Scheduling configures a report to execute automatically at recurring intervals. Common uses include daily error summaries, hourly security checks, weekly capacity reports, and recurring business metrics.

Schedule and time range

A schedule determines when Splunk starts the report. The report's earliest and latest settings determine which data it searches. For recurring reports, use a time range that matches the reporting interval and avoids accidental gaps or unnecessary overlap.

Relative time ranges are often useful because they move with each execution. For example, a daily report might search the previous completed day rather than the current partial day. The exact settings should account for the schedule, indexing latency, and the execution window.

The execution window is the period during which a scheduled search is expected to run. If a report is expensive or the Splunk scheduler is busy, it may start later than expected or compete with other scheduled searches.

Workload considerations

Do not schedule many expensive searches at the same time.
Prefer efficient filters, appropriate indexes, and bounded time ranges.
Review search execution history and scheduler status where available.
Consider whether a report truly needs frequent execution.
Retire obsolete scheduled reports so they do not consume resources.

Permissions, Ownership, and Sharing

A report has an owner, an app context, and permissions. The owner is the user account associated with the saved object and its management rights. App context determines the Splunk app scope in which the report is stored and made available.

Common sharing scopes include:

Private: Available only to the owner and authorized administrators or users with appropriate capabilities.
App-level: Available within the relevant app to users or roles that have access to that app.
Global: Available across apps when the deployment and permissions allow it.

Read permission controls who can view and run the report. Write permission controls who can modify or manage it. A user may be able to read a report without being allowed to change its SPL, schedule, ownership, or sharing settings.

Sharing the report does not automatically grant access to the data it searches. Verify that the target roles can access the underlying indexes, data models, lookups, field extractions, macros, and other knowledge objects used by the report.

See how to share a report for a focused permissions workflow.

Using Reports in Dashboards and External Destinations

Dashboard use

To add a saved report to a dashboard, open the dashboard editor, choose to add a panel, and select the saved report or report-backed data source where supported. Confirm that the panel's visualization, time range, tokens, and permissions work for the intended viewers.

Report-backed panels provide centrally maintained search logic. This helps prevent multiple dashboards from drifting apart when they are intended to show the same metric.

External embedding

Some Splunk environments support using scheduled-report output in external web content. Treat this as an integration that requires explicit authentication, authorization, transport protection, and exposure controls. Limit the data and users involved, and avoid exposing sensitive results through an unauthenticated or broadly accessible endpoint.

Embedding report output is not the same as exporting a CSV, PDF, or static screenshot. An export is a snapshot, while an embedded result may be retrieved or refreshed according to the configured integration.

Report, Alert, and Dashboard Panel Comparison

Report: Its primary purpose is reusable analysis. It runs manually or on a schedule and produces events, statistics, tables, or visualizations. It is a saved search or pivot.

Alert: Its primary purpose is detecting a condition and taking an action. It runs according to a trigger or schedule and produces a notification or response. It commonly uses a saved search as its base.

Inline-search dashboard panel: Its primary purpose is displaying a metric in one dashboard. It runs as part of the dashboard and displays panel results. Its search is stored inside the panel rather than as a separate report.

Report-backed dashboard panel: Its primary purpose is displaying reusable report logic in a dashboard. It runs through the referenced report and displays its results. The panel and report are separate objects with related permissions.

Report Lifecycle and Maintenance

Reports should be treated as maintained knowledge objects rather than permanent, unmanaged searches.

Name clearly: Include the purpose, data domain, and useful scope in the name.
Describe the logic: Record the data source, expected time range, owner, and intended audience.
Review dependencies: Track indexes, data models, fields, lookups, macros, and permissions used by the report.
Test changes: Rerun the report after changing SPL, data sources, field extractions, data models, schedules, or permissions.
Review ownership: Transfer or update ownership when responsibilities change.
Retire obsolete reports: Disable or delete reports that are no longer needed, especially expensive scheduled reports.

After changing a report, test it with representative time ranges and users. A report may work for its owner but fail for dashboard viewers or shared users because their roles cannot access a dependency.

Practical Examples

Save a recurring error summary

Create an SPL search that counts application errors by service, save it as a report, and run it manually during incident investigation. Then schedule it for daily review using a time range that covers the previous reporting period.

Turn a pivot into a reusable report

Build a visualization from an approved data model in Pivot and save it as a report. Analysts can rerun the same analysis without recreating the filters, aggregations, and visualization.

Reuse report logic in a dashboard

Convert an inline dashboard panel showing failed logins into a saved report. Use that report in a security dashboard and allow other authorized users to run it independently.

Share a report with an operations team

Set the report to the appropriate app or sharing scope, grant read access to an operations role, and confirm that role members can access the indexes and other objects used by the search.

Troubleshooting Reports

A shared report returns no results for another user

The user may lack access to the underlying indexes or data model.
The report may use private lookups, field extractions, macros, or other knowledge objects.
The user's manual time range may not include relevant events.

Verify role capabilities and index permissions, check the sharing scope of dependent objects, and rerun the report with an appropriate time range.

A scheduled report does not produce expected results

The schedule or relative earliest and latest settings may be incorrect.
The search may be expensive or delayed by workload limits.
Underlying data may arrive after the report's search window.

Review the schedule and time settings, inspect scheduler status and execution history where available, and account for indexing latency by adjusting the reporting window when necessary.

A report cannot be added to a dashboard

The report may be private or stored in an inaccessible app context.
The dashboard editor may not have permission to read the report.
The report may depend on fields or objects unavailable to dashboard viewers.

Review report permissions and app scope, confirm that dashboard users can read the report and its dependencies, and test it as a representative viewer.

A converted dashboard report does not match the original panel

Dashboard tokens or panel-specific time settings may not have been preserved.
The original panel may have used contextual inputs.
The visualization configuration may differ from the saved report.

Compare the saved search with the panel search, review token substitution and time-range configuration, and validate both with identical inputs.

Exam-Relevant Notes

A report is a reusable saved search or saved pivot.
A scheduled report is not a different kind of search definition; it is a report with automatic recurring execution configured.
An alert adds a trigger and action to search behavior; a report primarily presents reusable results.
An inline dashboard search is stored in the panel, while a report-backed panel references a separately managed report.
Sharing a report does not automatically grant access to its indexes, data models, or dependent knowledge objects.
Manual results depend on the selected time range, and scheduled results depend on both the schedule and the configured search window.
Clear names, descriptions, ownership, permissions, and regular testing are essential for report maintenance.

Reports provide a practical bridge between one-time SPL analysis and repeatable Splunk workflows. Start with a correct search or Pivot, save its definition, configure only the execution and sharing behavior you need, and test the complete result for every intended user.