Actions for a real-time alert are triggered the moment a defined condition is met and the system confirms it isn’t a transient blip. In practice, that “moment” ranges from milliseconds to several minutes depending on how the alert is configured: whether it uses event-driven evaluation or polling, whether a duration clause requires the condition to persist, and how the notification is ultimately delivered.
How the System Detects the Condition
The timing of an alert action starts with how the system checks for problems in the first place. There are two fundamental approaches, and each has a different impact on when your action fires.
Event-driven evaluation reacts the instant something happens. When a data point arrives that breaches a threshold, the system processes it immediately. Message queues and event buses push updates with near-zero delay, so the gap between “condition occurred” and “system knows about it” is measured in milliseconds. This is the architecture behind payment fraud alerts, security intrusion detection, and other scenarios where seconds matter.
Polling-based evaluation checks on a fixed schedule. The system repeatedly queries a metric at set intervals and compares the result against your threshold. If the condition is already breaching when the next poll runs, the alert fires then. If the breach happened one second after the last poll, you wait until the next cycle. In AWS CloudWatch, for example, alarms with a period of one minute or longer are evaluated once per minute. In Prometheus, the evaluation interval (commonly 15 or 30 seconds) determines how frequently alert rules are checked. The worst-case detection delay equals the length of one full polling interval.
Threshold Types Affect Timing
A static threshold is straightforward: if CPU usage exceeds 90%, fire the alert. The action triggers as soon as the evaluation cycle detects the breach, with no additional processing delay.
Dynamic thresholds, which use anomaly detection instead of a fixed number, take longer to evaluate. These systems analyze historical data to learn what “normal” looks like and set upper and lower bounds automatically. Azure Monitor’s dynamic thresholds, for instance, use 10 days of historical data to calculate seasonal patterns and won’t fire at all until they’ve collected at least three days and 30 samples of metric data. If the data’s behavior changes recently, the adjusted boundaries won’t reflect those changes immediately since the bounds are recalculated from the previous 10 days of metrics. So dynamic threshold alerts inherently have a slower, more conservative trigger compared to static ones.
Duration Clauses and Persistence Requirements
Most alerting systems let you add a condition that says “only fire if this problem persists for a certain amount of time.” This is the single biggest factor that delays an action trigger, and it’s there by design to prevent noisy, false-positive alerts.
In Prometheus, this is the for clause. When you set for: 10m, the system first detects the breach and puts the alert into a “pending” state. It then checks on every subsequent evaluation cycle that the condition is still true. Only after 10 continuous minutes of breaching does the alert transition to “firing” and trigger the action. If the condition resolves at minute 8, the alert resets and no action fires. Without a for clause, the alert fires on the very first evaluation where the condition is true.
AWS CloudWatch uses a similar concept with “Datapoints to Alarm.” You configure how many of the most recent evaluation periods must be in a breaching state before the alarm activates. If you set a 1-minute period with 3 evaluation periods and require 3 out of 3 datapoints to be breaching, the earliest an action can trigger is 3 minutes after the initial breach. If the evaluation window multiplied by the period length exceeds one day, CloudWatch slows evaluation down to once per hour.
Some systems use event-count thresholds instead of time windows. A stateful alert processor might require 3 matching events within a 5-minute window before triggering an action, then recover after 1 event within 1 minute. This approach is common for log-based alerts where you want to catch repeated errors, not one-off anomalies.
Windowing in Stream Processing
When alerts run on continuous data streams, the windowing strategy determines exactly when actions fire. Two common types behave quite differently.
Tumbling windows divide the data stream into fixed, non-overlapping time segments. A 5-minute tumbling window collects all events from 10:00 to 10:05, evaluates them, then starts fresh from 10:05 to 10:10. The action triggers at the end of the window. An event arriving at 10:01 won’t produce an alert until 10:05, meaning worst-case delay is nearly the full window length.
Sliding windows are more responsive. They output results only when the content of the window actually changes, meaning when an event enters or exits the window. So if a new data point pushes the aggregate past your threshold, the alert can fire immediately rather than waiting for a window boundary. Every sliding window contains at least one event, and evaluation happens continuously as the window moves.
Deduplication and Noise Suppression
Even after a condition is detected and confirmed, the alert system may still delay or suppress the action to reduce noise. When a new event arrives, the system compares it against all currently open alerts using a deduplication key (typically a combination of the source, service, and check that generated the event). If an open alert already describes the same issue on the same node, the system updates the existing alert rather than creating a new one and triggering a separate action.
This means the first occurrence of a problem triggers an action, but subsequent identical events do not. They update the severity or description of the existing alert instead. For example, a database query response time crossing 400ms might create an alert with minor severity. When a second event arrives showing it’s now over 600ms, the system recognizes the matching key, upgrades the alert to major severity, but doesn’t necessarily fire a brand-new notification. This is useful behavior, but it’s worth understanding because it means repeated threshold breaches don’t always produce repeated actions.
Delivery Channel Adds Its Own Delay
Once the system decides to fire an alert, the notification still has to reach you. The delivery method creates one final layer of latency.
- Webhooks deliver in near real-time, typically within milliseconds. They push data directly to an endpoint the moment the trigger fires, making them the fastest option for automated responses like scaling infrastructure or triggering an incident management workflow.
- SMS and push notifications generally arrive within a few seconds, though carrier delays can occasionally stretch this to 10-30 seconds.
- Email is the slowest common channel. Between SMTP relay hops, spam filtering, and inbox delivery, emails can take anywhere from a few seconds to several minutes. For time-sensitive alerts, email is a poor primary channel.
Putting the Timeline Together
The total time from “something went wrong” to “an action executes” is the sum of every stage: detection latency (milliseconds for event-driven, up to one polling interval for poll-based), threshold evaluation (instant for static, potentially days of warmup for dynamic), any persistence or duration requirement you’ve configured, deduplication checks (milliseconds of processing), and delivery channel latency. A well-tuned event-driven alert with no duration clause and a webhook endpoint can trigger an action in under a second. A polling-based alert with a 5-minute evaluation period, a requirement for 3 consecutive breaching datapoints, and email delivery could easily take 15 to 20 minutes.
The “real-time” label generally means the system processes data within milliseconds to seconds of creation. Near-real-time systems introduce delays of seconds to minutes. Where your alert falls on that spectrum depends almost entirely on the configuration choices above, not on the platform itself.