Incidents · Business
Anomaly-driven incident proposals
Most status-page tools wait for customers to complain. StatusPulse uses its anomaly model to pre-stage incidents before subscribers notice. No other tool can — they don't have the ML.
Why you need it
The AnomalyAlertEvaluator fires sustained-
crossing alerts (1 hour cooldown). On every fire,
StatusPulse pre-stages a Proposed incident with severity
mapped from the verdict (Down → Major, Degraded → Minor),
the affected monitor linked as a component, and an
internal-only initial update explaining the signal.
- Internal-only by default. Proposals are never on the public page, never to subscribers, no notifications fire. Operator reviews them on the Dashboard → Incidents page.
- One-click promote. Hit "Accept" and the incident transitions to Investigating, the seed update flips to public, and subscriber notifications enqueue. EngineLocked = true so the auto engine stops touching it.
- One-click dismiss. False positive? Soft-delete the proposal; the AnomalyAlertEvaluator's cooldown keeps it from re-proposing in the same window.
- De-duped at the service layer. If a proposal is already open for a monitor, a repeat fire reuses the existing row.
Where it pays off
The differentiator framing: this is unique because StatusPulse runs the cross-tenant anomaly model that other tools don't ship. Statuspage.io / BetterStack / Pingdom — none can do this.
- Latency degradation. Probe is still "Up" but anomaly score crosses threshold — proposal lands before customer tickets.
- Regional drift. One region's checks drift while others are clean — anomaly catches it faster than uniform thresholds.
- Periodic-but-real degradation. Cron-job-induced spikes that fixed thresholds miss but the seasonal model catches.
Available on Business. Already on StatusPulse? See the full config in Help →
Related
Try Anomaly-driven incident proposals in StatusPulse
5 probes, 1 status page, forever. No credit card. US or EU host — you choose.