Detectors and Alerts

The detector stack

Edge runs over twenty detectors on a rolling schedule. Fast detectors run every minute and catch acute incidents: traffic spikes, credential-stuffing signatures, path abuse, origin slowdowns. Hourly detectors catch the slower patterns: gradual escalation, bot-dominated networks, catalogue crawling, reconnaissance scanners, fake Googlebots, repeat offenders. Certificate checks run every six hours, and a continuous heartbeat check pages you if your data feed itself goes silent.

Two hourly detectors watch the bot population itself. New bot detected fires when a name that has never crawled your store arrives with real volume, whether it is a recognised crawler or a made-up name inside the unclassified group. Bot volume spike fires when a known bot runs at a multiple of its own usual rate, measured against its own recent history rather than a fixed threshold. Both alerts link straight to that bot's drill-down on the Bots & agents page, and both are detection-only: a new bot may be a vendor integration you just switched on, so what happens next is your call.

Impossible browser version watches for automation that fabricates its identity outright: a fleet claiming a browser version newer than anything your real shoppers run. The detector calibrates from your own human traffic, so there is no version list to go stale, and stores without Bot Management data never see a false alarm; without a real-shopper baseline it stays quiet. The alert carries a drafted challenge rule matched to the exact fabricated version string, which cannot touch a real shopper because no real browser runs a version that does not exist. Like every drafted rule, it arrives disabled and nothing changes until you enable it.

A handful of high-power detectors ship disabled so you can validate their thresholds against your own traffic before turning them on from the Rules page. The full catalogue, with what each one catches and its default state, is in How Detectors Work.

When an alert fires

1. The detector opens an alert with status "open".
2. Notifications go out on your configured channels: email, webhook, Microsoft Teams, or Slack (see Sending Alerts to Teams and Slack).
3. The alert appears on the Alerts page and the Overview active-alerts panel.
4. Each later evaluation updates the alert while the condition persists, and most detectors auto-resolve it when the condition clears.

What an alert gives you

Open any alert and you get, in reading order:

• A one-sentence summary in natural language, plus a short AI-written brief explaining what happened and why it matters.
• A detector-specific playbook: what to check, and a "when to close" criterion.
• Where the alert maps to a "stop this traffic" situation, a drafted eCDN rule you can copy into Business Manager or apply in one click (Applying and Rolling Back Protections).
• If other detectors are firing on the same target, a banner linking the correlated incident so you investigate once (Correlated Incidents).

Alert lifecycle

• Open — the detector is currently tripping
• Acknowledged — an operator has seen it and is investigating
• Resolved — the condition cleared (automatic) or an operator resolved it manually

For the full triage workflow see Investigating an Alert.