9.1 Scheduled Reports
Key Takeaways
- A scheduled report is a saved report that runs automatically on a schedule and can deliver results through actions such as email each time it runs.
- Unlike an alert, a scheduled report action does not evaluate trigger conditions — the action runs every scheduled execution.
- When scheduling, set both the run schedule (preset or cron) and the search time range relative to each run (for example Last 24 hours ending at schedule time).
- Scheduled reports cannot keep a time range picker; Splunk removes the picker when you enable a schedule.
- Open Edit Schedule from the Reports listing (or Settings > Searches, Reports, and Alerts) to configure schedule, time range, and email delivery.
Why scheduled reports matter on the User exam
Domain 8.0 Creating Scheduled Reports and Alerts is only 5% of Splunk Core Certified User, but exam items here are crisp and easy to miss if you confuse reports with alerts. A scheduled report is a saved report that Splunk re-runs on a recurring schedule. Each run can optionally launch one or more actions — most commonly email delivery of the results — so managers, operators, or auditors get a consistent package of statistics or events without opening Search & Reporting themselves.
Stay at User scope: you schedule existing reports, set relative time ranges, and attach simple delivery actions. You do not need Enterprise Security correlation searches, notable-event workflows, or deep scheduler priority tuning.
1. What a scheduled report is
Start from a normal report (a saved search with a presentation). Scheduling adds three layers of behavior:
- When it runs — the schedule interval (hourly, daily, weekly, or a cron expression).
- What data it covers — the time range of events collected on each run, expressed relative to the moment the schedule fires.
- What happens after it runs — optional actions such as email, which export or notify with that run's results.
Scheduled report vs alert (high-level contrast)
| Concept | Scheduled report | Alert |
|---|---|---|
| Purpose | Recurring delivery of results | Condition-based notification |
| Action firing | Action runs every scheduled run | Action runs only if trigger conditions match |
| Typical use | Daily KPI email, weekly PDF summary | "Email me if error count > 50" |
| Trigger conditions | None for the action | Required for meaningful alerting |
Exam trap: An email attached to a scheduled report is not gated by "number of results is greater than X." If the report is scheduled for 08:00 daily, stakeholders get email at 08:00 (subject to mail settings and permissions) whether the result set is empty, tiny, or huge — unless your search itself returns nothing useful to attach. Alerts are the object type that adds trigger logic.
2. Configure the schedule
Open scheduling from the Reports listing in the app bar (Edit → Edit Schedule), from an expanded report row's scheduling controls, or from Settings → Searches, Reports, and Alerts. Your role needs the schedule_search capability to schedule.
Schedule choices
| Option | What you set | User-level example |
|---|---|---|
| Preset schedule | Run every hour, day, week, and similar presets | Daily operations digest |
| Cron schedule | Custom cron expression for exact timing | 0 8 * * 1-5 — 08:00 weekdays |
| Time zone | Schedule clock context | Align run time with stakeholder locale |
Presets are enough for most User scenarios. Cron appears when the exam describes "every weekday at 6 AM" style requirements.
Important UI rule: Scheduled reports cannot include a time range picker. If the report had an interactive picker, Splunk removes it when you schedule the report. Interactive explorers stay unscheduled; automated jobs use a fixed schedule plus a fixed (or explicitly set) time range.
Scheduled reports also run as owner. If a shared report was set to run as user, scheduling updates it to run as owner so permissions stay consistent for the automated job.
3. Time range relative to the schedule
The schedule answers when the search starts. The time range answers which events are included. That time range is evaluated relative to each scheduled run.
Examples:
| Schedule | Time range setting | What each run searches |
|---|---|---|
| Every hour on the hour | Last 60 minutes | The previous hour of events |
| Daily at 07:00 | Yesterday | The prior calendar day |
| Daily at 08:00 | Last 24 hours | Rolling 24 hours ending at 08:00 |
| Weekly Monday 09:00 | Last 7 days | Prior week ending at run time |
Best-practice pairing
Match the search window to the schedule interval so you avoid gaps and overlaps:
- Hourly schedule + Last 60 minutes → contiguous hourly slices.
- Daily schedule + Yesterday or Last 24 hours → choose based on whether you want calendar days or rolling windows.
If the search time range is shorter than the gap between runs, some events may never be evaluated. If it is much longer than the interval, consecutive emails may duplicate the same incidents. User exam items often test that you understand relative windows ("last 24 hours at schedule time"), not absolute calendar pickers.
You can keep the report's existing time range or override it in the Edit Schedule dialog. Overrides are common when a report used for interactive exploration (Last 15 minutes) should instead email Yesterday's stats.
4. Email delivery of report results
When you schedule a report, you may define actions that fire each time the report runs. Email notification is the User-level delivery method to memorize.
Typical email options include:
- Recipients (To / CC / BCC as configured)
- Subject and message body (may include tokens such as links to the report or results)
- Inline results (table, raw, or CSV-style presentation)
- Attachments such as CSV or PDF when enabled in the environment
Workflow summary:
- Build and save the search as a report (Domain 6.0 skills).
- Open Edit Schedule.
- Enable scheduling; pick preset or cron.
- Set the time range relative to the schedule.
- Add Email as an action and fill recipients / content options.
- Save and verify the next expected run.
Other actions exist (webhook, output to lookup, log event), but User blueprint emphasis is understanding that scheduled report actions run on every execution, with email as the classic delivery path.
5. Exam scenarios and traps
Scenario: Leadership wants a Monday morning table of top failing hosts for the prior week emailed to ops@example.com.
- Save a
stats/topreport. - Schedule weekly Mondays.
- Time range Last 7 days.
- Email action to the ops list.
- Do not convert it to an alert unless they only want mail when failures exceed a threshold.
Scenario: Someone asks why the scheduled report still emailed when zero critical errors appeared.
- Correct explanation: scheduled report actions are not condition-gated like alerts.
Trap list:
- Confusing Save As → Report (then schedule) with Save As → Alert.
- Leaving the interactive time range picker enabled and expecting it to survive scheduling.
- Setting schedule "every hour" with time range "Last 24 hours" without realizing heavy overlap.
- Thinking scheduling requires Admin-only
savedsearches.confedits — User configures this in Splunk Web.
Master the triad: schedule + relative time range + always-on action, then move to alerts where conditions decide whether anyone is notified.
How does a scheduled report's email action differ from a typical alert's email action?
A report is scheduled to run every day at 08:00 with a time range of Last 24 hours. What data does the 08:00 Monday run cover?
What happens to a report's time range picker when you schedule the report?