VMware ESXi and vSphere Cluster Management

Splunk Reports Overview

Learn what Splunk reports are, how to create them from searches or Pivots, and how to run, schedule, share, dashboard, and manage them.

A Splunk report is a reusable saved knowledge object based on a search or a Pivot data model exploration. Instead of rebuilding the same analysis each time, you save its definition and run it again when needed.

A one-time search is useful for immediate investigation. A report persists after that session, can be reused by authorized users, can be placed on a dashboard, and can optionally run on a recurring schedule. Reports support recurring analysis, team reporting, dashboard visualization, and controlled distribution of results.

Prerequisites and key terms

You should be comfortable navigating Splunk, running and interpreting searches, selecting time ranges, and understanding basic users, roles, apps, and permissions. Familiarity with Search Processing Language (SPL) or with Pivot and data models is also useful.

Report: A saved reusable definition for returning search or Pivot results.
Saved search: A persisted search definition that can be reused as a report and may be scheduled.
Search Processing Language (SPL): The language used to define searches that can be saved as reports.
Pivot: A point-and-click method for exploring data models that can be saved as a report.
Knowledge object: A reusable Splunk configuration object, such as a saved report, with ownership and sharing settings.
Ad hoc execution: Manually running a report when needed instead of waiting for its schedule.
Scheduled report: A report configured to run automatically at recurring intervals.
Dashboard panel: A dashboard component that displays search or report output.
Inline search: A search defined directly inside a dashboard panel rather than maintained as a separate saved report.
Permissions: Authorization settings that control who can view, edit, or share a report.

How a report works

A report stores the definition of an analysis. The definition may be an SPL search or a Pivot configuration. When the report runs, that underlying definition determines the results returned.

For example, an analyst can develop an SPL search for failed authentication events, test it, and save it as a report. The same analysis can then be run during future investigations without recreating the search. A business user might instead build an aggregation from an approved data model with Pivot and save that exploration as a report.

A report definition is not the same thing as a permanently fixed result set. Its output depends on the underlying search or Pivot, selected time range, available data, filters, and any dashboard context supplied when it is used.

Report source types

SPL search reports

A standard SPL search is a flexible source for a report. This approach is appropriate when the analysis needs specialized filtering, transformations, statistical commands, or other search logic.

index=web status>=500
| stats count by host, status
| sort - count

After testing a search in the Search app, save it as a report. The saved object retains the search definition and the configuration associated with its use, such as its name, description, owner, app context, time range, and optional schedule.

Pivot reports

A Pivot uses point-and-click controls to explore a data model. It can be useful for users who want to select fields, filters, and aggregations without writing the entire SPL expression manually.

When a Pivot is saved as a report, the Pivot definition determines the returned results. Validate the data model, fields, filters, and aggregation before sharing or scheduling the report.

Ways to create a report

Starting location: Search app

Creation action: Run and test an SPL search, then save the completed search as a report.

Appropriate use case: Preserve an investigation, operational query, or recurring analysis.

Resulting report source: SPL search.

Starting location: Pivot interface

Creation action: Build a Pivot and choose the option to save it as a report.

Appropriate use case: Preserve a data model exploration and its aggregation.

Resulting report source: Pivot.

Starting location: Settings > Searches and reports

Creation action: Select New, then provide the report definition and configuration.

Appropriate use case: Create or manage a report directly from the administration interface.

Resulting report source: The search or Pivot definition entered during creation.

Starting location: Dashboard panel

Creation action: Convert an inline-search panel into a report.

Appropriate use case: Move panel logic into a reusable object that can be maintained and used elsewhere.

Resulting report source: The panel's search, saved as a separate report.

Save an existing search

Open the Search app.
Build and test the SPL search.
Confirm that its time range and results are appropriate.
Save the completed search as a report.
Give the report a clear name and description, then review its owner, app context, permissions, and optional schedule.

Save a Pivot

Open the Pivot interface.
Select the relevant data model, fields, filters, and aggregations.
Validate that the output represents the intended analysis.
Choose the option to save the Pivot as a report.
Configure its name, ownership, sharing, time range, and schedule as appropriate.

Create a report from Settings

Use Settings > Searches and reports > New to create and manage reports through the settings interface. This route is useful when you already know the desired report definition or need to manage report properties directly rather than starting in Search or Pivot.

Convert an inline dashboard search

A dashboard panel may contain an inline search that exists only inside that panel. Converting it to a report moves the logic into a reusable saved object. The dashboard can then display the report, and other dashboards or users can reuse the same definition when their permissions allow it.

Running reports manually

Manual, or ad hoc, execution runs a report immediately when a user requests it. A user can review results for the report's configured range or select a different time range when the interface permits it.

Ad hoc execution is useful when an analyst needs results outside the normal schedule, wants to validate a change, or is investigating a current issue. For example, a daily operations report can be run manually for the last hour during an incident instead of waiting for the next morning's scheduled run.

Scheduling reports

A scheduled report executes automatically at recurring intervals. Common schedules include daily, weekly, or other periodic operational reporting.

The schedule and time range work together. The schedule determines when the report runs; the time range determines the data period used to produce that run's result set. A report scheduled each morning with a preceding-day time range can summarize the previous day's application errors for a service owner.

Before enabling a schedule, check that the cadence matches the reporting requirement and that the time range covers the intended period. Changing either setting can change the data included in future output.

Sharing and permissions

Report access is governed by permissions. Depending on the configuration, a report may be available only to its owner, to other users through an app, or more broadly within an authorized Splunk environment.

Users need appropriate permissions to view, run, modify, or share a report. Sharing a report does not automatically grant access to every data source used by its search. The intended users also need access to the relevant app and data.

Use a private scope while developing or validating a report.
Share with the appropriate app or team when the report is ready for operational use.
Use broader sharing only when the report and its data are suitable for that audience.
Review ownership and edit permissions before allowing others to maintain the report.

Using reports in dashboards

A saved report can be added to a dashboard as the source for a dashboard panel. The panel displays the report's results, while the report stores the reusable search or Pivot definition.

Separating the definition from the panel can reduce duplication. If several panels or dashboards need the same logic, a saved report provides one place to maintain that logic instead of copying an inline search into each panel.

When a dashboard panel and its corresponding report show different results, determine whether the panel actually uses the saved report or still contains an independent inline search. Also compare time ranges, dashboard tokens, filters, and recent changes to the report.

Embedding scheduled report output

Scheduled report output can be prepared for presentation in an authorized external website. This is useful when an approved audience needs recurring results without opening the normal Splunk dashboard experience.

External embedding must be considered together with access control and data exposure. Before publishing, review the report's sharing permissions, the data returned by its search, external access controls, and the security requirements of the destination. A scheduled result should contain only information approved for that audience.

Report management lifecycle

Reports should be managed as operational assets rather than created once and forgotten.

Create: Start with a tested SPL search, Pivot, settings form, or dashboard-panel conversion.
Name and describe: Use a name that identifies the purpose, data, and reporting audience. Add a description so later users understand the report.
Run: Execute the report manually to verify its output and time range.
Schedule: Enable recurring execution only when the cadence and reporting window are understood.
Share: Assign an appropriate owner, app context, and sharing scope.
Use: Add the report to dashboards or use it for team reporting and authorized external presentation.
Update: Change the search or Pivot definition, time range, schedule, or permissions when requirements change.
Retire or disable: Remove obsolete dashboard references and disable or retire reports that are no longer needed.

What reports can be used for

Capability: Manual execution

Purpose: Obtain results immediately for an investigation or an unusual time range.

Typical example: Run a daily authentication report for the last hour during an incident.

Key consideration: Confirm the selected time range before interpreting results.

Capability: Scheduled execution

Purpose: Produce recurring operational or management results automatically.

Typical example: Summarize application errors each morning for the preceding day.

Key consideration: Align schedule cadence and reporting time range.

Capability: Permission-based sharing

Purpose: Let authorized users run a common analysis without rebuilding it.

Typical example: Share an infrastructure-health report with members of an operations app.

Key consideration: Check report permissions, app access, ownership, and data access.

Capability: Dashboard use

Purpose: Display reusable report results in a dashboard panel.

Typical example: Use one saved report for top source IP addresses in multiple views.

Key consideration: Keep panel settings and report definitions consistent.

Capability: External embedding

Purpose: Present approved scheduled results in an authorized external site.

Typical example: Publish a recurring service summary to an approved external audience.

Key consideration: Review access controls and data exposure before publication.

Troubleshooting reports

Other users cannot find or run a report

Verify the report's sharing scope and permissions.
Confirm that the intended users can access the relevant app and data.
Check whether the report is private or owned by another user without appropriate sharing.

A scheduled report covers the wrong data period

Review the report's selected time range.
Compare the schedule cadence with the intended reporting window.
Run the report manually to validate its current results.

A dashboard panel and its report show different results

Confirm whether the panel uses the saved report or an independent inline search.
Compare time-range settings, dashboard tokens, and filters.
Verify that recent report changes were reflected in the panel configuration.

A Pivot-based report is not suitable for the analysis

Confirm that the required data model and fields are available.
Validate the Pivot aggregation and filters.
Determine whether an SPL-based report is needed for more specialized logic.

External presentation exposes too much data

Review report sharing permissions and external access controls.
Verify that the search returns only approved data.
Confirm that the scheduled output and presentation destination meet organizational security requirements.

Exam-relevant notes

A report is a persistent reusable knowledge object, not merely the result of a one-time search.
Reports can originate from SPL searches or Pivot explorations.
The underlying search or Pivot definition determines the returned results.
Manual execution and scheduled execution are different ways to run the same saved definition.
Schedule cadence and time range jointly influence the generated result set.
Permissions control who can view, run, edit, and share a report.
A dashboard panel can use a saved report, while an inline search remains maintained inside the panel.
Changes to a report can affect scheduled output and downstream dashboards.

For a concise reference, see Reports Overview.