Anomaly detection

Why you need it

Thresholds catch failure after it starts. By the time your alert fires, your customer's already typed the support ticket. The forecast tab is the head-start — a probe is trending toward trouble, and you get to act before the banner turns red.

• See trouble coming. Two probability lines (Degraded, Down) on every probe's Forecast tab — rising before the failure, not after.
• Catch "internet weather." When AWS us-east-1 has a bad afternoon, your forecast lifts even if your own probe hasn't tipped yet. Cross-tenant signal you can't get from your own data alone.
• Catch the slow drift. Latency creeping up over hours, intermittent 5xx, packet-loss bursts that recover — the leading indicators that thresholds miss.
• Catch the rhythm. Probes that fail Thursday 3am UTC get a higher forecast at Thursday 3am UTC. The model learns the pattern; you don't configure it.
• Privacy-safe by design. Tenant ID, probe ID, probe name, and probe URL never enter training. Opt out entirely if you prefer — one toggle.

Where it pays off

Turn forecasting on when "five minutes early" changes the outcome:

• Customer-facing APIs and checkout flows. Three minutes of head-start to roll a deploy back or page the on-call is the difference between near-miss and incident.
• High-traffic third-party dependencies. A payment gateway or cloud-region health endpoint — the cross-tenant signal is your early-warning system.
• Services with day-of-week patterns. Anything where "this hour on this day" historically matters.
• Mature operations. Once your deterministic alerts feel reliable, the forecast tab is the next layer of signal.

Not the right tool when: your probe is brand-new (forecasts are suppressed for the first 30 results) or your governance forbids contributing aggregate signals to a shared model (the opt-out is one click).

Related

• HTTP / HTTPS probe
• TCP / port probe
• Ping probe
• Heartbeat probe
• Incidents & alerts
• Multi-region checks