Simple explanation
An alert is a search that watches for a specific condition and takes action when it's met — this lesson covers the two fundamental modes an alert can run in.
Technical explanation
- Scheduled alerts — run on a defined interval (like every 5 minutes), checking a relative time window each time; the more common, resource-efficient choice for most use cases, since they only consume resources during their scheduled runs rather than continuously.
- Real-time alerts — continuously monitor incoming data as it arrives, triggering as close to immediately as possible when a condition is met; more resource-intensive to run continuously, generally reserved for genuinely time-critical use cases where even a few minutes' delay matters.
- Trigger conditions — an alert doesn't just run a search, it evaluates the RESULTS against a defined condition (like "number of results > 0" or "a specific field's value crosses a threshold") to decide whether to actually fire.
- Trigger settings: "once" (fire a single alert even if multiple events match) vs. "for each result" (fire a separate alert instance per matching result) — this choice significantly affects how much alert volume a given condition produces.
- Throttling — suppressing repeated alert firings for the same underlying condition within a defined window, preventing alert fatigue from the same issue firing repeatedly before anyone's had a chance to respond to the first notification.
Synonyms / related terms
| Term | Means | |---|---| | Trigger condition | The rule determining whether an alert's search results actually cause it to fire | | Throttling | Suppressing repeated alert firings for the same condition within a time window |
Concept Check
"A security team needs to detect a specific critical event within seconds of it occurring, not minutes, and configures a scheduled alert running every 5 minutes instead." A scheduled alert, however frequent, inherently introduces a delay up to its full interval — for genuinely seconds-level detection urgency, a real-time alert is the appropriate choice, accepting its higher resource cost specifically because the latency requirement demands it.
Interview-style Q&A
Q: Why are scheduled alerts the default recommendation for most use cases, rather than real-time? A: "Real-time alerts consume resources continuously, for as long as they're active, regardless of whether the condition they're watching for actually occurs. Most alerting needs don't genuinely require sub-minute detection — a scheduled alert running every few minutes provides effectively 'fast enough' detection for the vast majority of use cases, at a fraction of the ongoing resource cost. Real-time should be reserved specifically for cases where that extra speed is a real, justified requirement, not a default choice made without considering the trade-off."
Memory trick
"Scheduled Checks Periodically, Real-time Watches Continuously" — the core distinction between the two alert types, and why one costs more than the other.