Investigating an Alert

The shape of an alert page

Every alert page is organised top-to-bottom for how an operator actually reads an incident:

1. Header — severity, status, and a live-state pill that tells you whether the underlying condition is still happening.
2. What happened — a one-sentence summary in natural language. "🇬🇧 Cloudflare (AS13335) · GB is sending 2.7× its normal traffic — 1.23k req/min vs. 450 baseline."
3. The AI brief — a card titled "What happened, in plain English": a few sentences explaining what tripped, why it matters for a storefront, and what to look at first. It is written by AI from the alert's own data; the numbers and any drafted rule come from the deterministic pipeline, not the AI. See Plain-English Summaries.
4. Incident banner — if other detectors are currently firing on the same target, a banner tells you this alert is part of a correlated incident, how many detectors agree, and the combined confidence. Click through to investigate once instead of per-alert. See Correlated Incidents.
5. What to do — a detector-specific playbook with 3–5 concrete actions, plus a "When to close" criterion.
6. Stop this now — where the alert maps to a blockable pattern, the drafted eCDN rule with copy-paste text and (on Growth and above, for owners) a one-click Apply on my eCDN button. See Applying and Rolling Back Protections.
7. Related open alerts — other alerts sharing the same target or the same detector kind.
8. Event timeline — what happened when, in plain English.
9. Rule details — the raw detector mechanics (thresholds, window sizes, context). Collapsed by default; for SREs.

Live / Cooling / Stale

Every alert has a small coloured pill near the header:

• Live (red, pulsing) — the detector evaluated this within the last 5 minutes. The underlying condition is ongoing.
• Cooling (amber) — 5–60 minutes since last update. The condition may have just stopped.
• Stale (grey) — more than an hour since last update. The incident has likely passed even if the alert is still technically open.

Use this to prioritise: Live alerts need attention now; Stale alerts can usually be resolved without investigation. Open alerts refresh automatically every 30 seconds while you have the page open, so you can watch a condition cool without reloading.

Severity

• Info — worth knowing about, not urgent
• Warning — the detector's primary threshold tripped
• Critical — threshold exceeded by 3× or a novel condition (e.g. new-traffic ASN from a type we expect clean traffic from)

Severity is shown as a coloured left-rail on the Alerts list and as a pill on the detail page.

The Alerts list

The Alerts page groups open alerts by detector kind into collapsible sections, with chip-style filters across the top. Click a chip to narrow to one detector. The list shows an honest "Showing X of Y" total with a Load more control, and refreshes automatically every 30 seconds on the open-alerts tab.

Impact ordering

The list is sorted by Impact by default. That ranks alerts by what the network behind them is actually costing your origin, then by how long the condition has been running.

Newest-first ordering, which used to be the default, has a failure mode worth understanding: a serious problem that started two days ago sinks below every smaller alert raised since. Impact ordering keeps it near the top for as long as it matters. Use the Newest button if you want the old behaviour, for example when you are checking what has happened in the last few minutes.

If your source is not sending a bot score, impact falls back to request volume and the page labels it as such.

What the row badges mean

Badge	Meaning
Sustained	The condition has been firing continuously for more than six hours. It is persistent rather than a passing spike. Descriptive only, it does not change the severity or send anything extra
Firing 2d 9h	How long the condition has been continuously true
×N flares	The condition has stopped and restarted N times. It is tracked as one alert rather than a new one per cycle, so this is a count of the flapping and not a backlog
Clearing	The condition has stopped. The alert stays open briefly in case it comes straight back, and closes on its own if it does not

Note that Clearing is not the same as the Cooling state described above. Cooling is about how recently the detector last evaluated the alert. Clearing means the condition itself has stopped and the alert is on its way out.

Acknowledging vs resolving

• Acknowledge — "I've seen this, I'm investigating." The detector keeps evaluating. The alert moves to the Acknowledged tab, stops appearing in the unread count, but continues to update if the condition persists.
• Resolve — "I've taken action (or the condition cleared)." The alert moves to Resolved and stops updating.

Most detectors auto-resolve when the condition clears (e.g. an ASN's ratio drops below the multiplier for a sustained period). Manual resolution is for when you've applied a rule or decided to accept the alert.

When to close — the "When to close" hint

Every detector has a specific close criterion written into its playbook. Example from ASN Spike: "Close when this (ASN, country) pair's ratio returns below 1.5× the type-specific multiplier for 15 minutes, or when a mitigation is in place."

This takes the "have I done enough?" guesswork out of resolution. If the criterion is met, close. If not, acknowledge and keep watching.

Pausing alert emails

If you're in the middle of a known incident and don't want more notifications, use Settings → Pause alert emails. Detectors keep firing and building an audit trail; webhooks still fire (so on-call integrations keep working); email, Teams, and Slack messages stop until you resume. See Pausing Alert Emails.