9.2 Describing and Creating Alerts

Splunk Core Certified User Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts & Logistics 1.2 Study Strategy & Learning Path

2 Splunk Basics

2.1 Splunk Components 2.2 Uses of Splunk 2.3 Splunk Apps 2.4 User Settings & Basic Navigation

3 Basic Searching

3.1 Running Basic Searches 3.2 Setting Time Ranges 3.3 Contents of Search Results 3.4 Refining Searches 3.5 Using the Timeline 3.6 Working with Events 3.7 Controlling Search Jobs 3.8 Saving Search Results

4 Using Fields in Searches

4.1 Understanding Fields 4.2 Using Fields in Searches 4.3 The Fields Sidebar

5 Search Language Fundamentals

5.1 Basic Search Commands & Practices 5.2 The Search Pipeline 5.3 Specifying Indexes in Searches 5.4 table, rename, fields, dedup, and sort

6 Using Basic Transforming Commands

6.1 The top Command 6.2 The rare Command 6.3 The stats Command

7 Creating Reports and Dashboards

7.1 Saving and Editing Reports 7.2 Statistical Table Reports 7.3 Chart Visualization Reports 7.4 Creating Dashboards and Adding Reports 7.5 Editing Dashboards

8 Creating and Using Lookups

8.1 Lookup Concepts and File Examples 8.2 Creating Lookup Files and Definitions 8.3 Configuring Automatic Lookups 8.4 Using Lookups in Searches

9 Creating Scheduled Reports and Alerts

9.1 Scheduled Reports 9.2 Describing and Creating Alerts 9.3 Viewing Fired Alerts

9.2 Describing and Creating Alerts

Key Takeaways Explain This Topic AI

An alert is a saved search that runs on a schedule or in real time and fires actions only when trigger conditions are met.

Scheduled alerts run at intervals and evaluate result-count or field-count conditions; real-time alerts search continuously and can trigger per result or on a rolling window.

Trigger frequency choices include once per search run (digest) versus once for each matching result (per-result).

Throttling (suppression) limits how often actions re-fire after a trigger so you are not flooded with duplicate emails.

Create an alert from Search with Save As → Alert, then configure type, triggers, throttle, and actions such as email or list in Triggered Alerts.

Last updated: August 2026

Alerts at User level

An alert is a saved search designed for monitoring. Splunk runs the search on a schedule or continuously in real time , evaluates trigger conditions against the results, and — only when those conditions match — executes alert actions . That conditional step is the defining difference from a scheduled report.

Domain topics 8.3 and 8.4 expect you to describe alert types, create an alert from a search, set triggers and throttling, and attach basic actions. Keep Enterprise Security correlation and notable-event frameworks out of scope.

1. Alert vs scheduled report

• Question Scheduled report Alert
• Why does it exist? Deliver recurring results Notify when a condition appears
• When do actions run? Every scheduled run Only when trigger conditions match
• Do you configure triggers? No (for the action) Yes — result/field counts or custom conditions
• Example Email yesterday's sales table every morning Email when failed logins exceed 20 in an hour

Memory hook: Reports deliver on a clock. Alerts deliver on a condition (checked on a clock or in real time).

Both objects can email results. The exam cares whether that email is unconditional (report schedule) or conditional (alert trigger).

2. Scheduled alerts vs real-time alerts

Alert type is about search timing , not about whether email exists.

Scheduled alerts

Search runs on a preset schedule or cron expression (similar mental model to scheduled reports).

After each run, Splunk evaluates trigger conditions (for example number of results, number of hosts, or a custom condition).

If conditions match, the alert can trigger once for that result set or once per matching result .

Usually lighter on resources than continuous real-time searches — prefer scheduled alerts when minute-level detection is not required.

Real-time alerts

Search runs continuously .

Per-result mode: each matching event can trigger the alert (also called per-result alerting).

Rolling time window mode: evaluate counts inside a moving window (for example more than 10 results in 5 minutes).

More resource-intensive; Splunk guidance often says prefer scheduled alerts when possible.

• Alert type When it searches Typical trigger options Throttling
• Scheduled On a schedule / cron Result or field counts; once or per result Suppression period
• Real-time (per-result) Continuously Each result triggers Suppression period (+ optional fields)

Real-time (rolling window) Continuously over a window Counts inside the window; once or per result Suppression period

User exam focus: Know that both types exist, that real-time is continuous and costlier, and that scheduled alerts combine a schedule with conditions (unlike scheduled reports).

3. Trigger conditions and trigger frequency

Trigger configuration answers two questions:

What pattern in the results should count as a fire?

How many times should actions run when that pattern appears?

• Common condition ideas (scheduled / rolling-window style)
• Number of Results is greater than / less than / equal to a threshold
• Field-oriented counts such as number of hosts
• Custom conditions that further filter the result set

Example: search for status=500 over the last 15 minutes on a 15-minute schedule; trigger when Number of Results is greater than 50 .

Once vs for each result

• Setting Behavior Also called Good for
• Trigger once One action bundle for the matching result set Digest mode Single email summarizing many events

Trigger for each result Separate trigger per matching row/event Per-result One notification per offending host or user

If 80 error events match and you choose for each result , you can generate up to 80 action executions before throttling. That is why throttling matters.

4. Throttling (suppression)

Throttling suppresses additional alert actions for a configured period after a trigger so the same condition does not spam inboxes.

Key points:

Trigger conditions decide whether the alert is eligible to fire.

Throttling decides how soon it may fire again after a successful trigger.

Configure a suppression time period (must be greater than zero when enabled).

Some designs also suppress per field values (for example per host ) so one noisy host does not silence others — know the concept; deep per-field design is secondary at User level.

Scenario: Real-time per-result alert on every failed login without throttling can email continuously during an attack. Adding a 10-minute throttle collapses the storm into manageable notifications.

5. Create an alert from a search (User workflow)

Run and refine the monitoring search in Search & Reporting (tight time range, precise filters).

Choose Save As → Alert .

Name the alert; set permissions appropriate to your sharing needs (private vs app).

Choose alert type : scheduled or real-time.

For scheduled: set schedule and evaluate trigger conditions; choose once vs per result.

For real-time: choose per-result or rolling-window triggering.

Optionally enable throttle and set the suppression window.

Attach actions — memorize these User-level actions:

• Email — notify recipients with results / links
• List in Triggered Alerts (Add to Triggered Alerts) — show the fire on the Activity page

Save and verify with a controlled test when possible.

Severity levels (Info, Low, Medium, High, Critical) help sort fires later on the Triggered Alerts page; they do not replace trigger logic.

6. Exam traps

Choosing Alert when the requirement is "email the dashboard stats every Monday regardless of values" → that is a scheduled report .

Choosing scheduled report when the requirement is "email only if count > 100" → that is an alert .

Enabling real-time per-result alerting for a high-volume sourcetype with no throttle → resource and email flood risk.

Forgetting that List in Triggered Alerts is an action you enable — not every alert automatically appears unless configured to list there (per Splunk's monitor/triggered-alerts action model).

Practice one lab path end-to-end: search → Save As Alert → scheduled + number of results → throttle → email + list. That single path covers most of topics 8.3 and 8.4.