Core features

Alerts and incidents

The alerting model is designed around incidents and recovery, not one notification per failed request.

Incident lifecycle

Repeated failures open an incident. Subsequent checks update its timeline. Recovery closes the same incident rather than creating an unrelated "up" event.

09:42  first timeout
09:43  second timeout
09:43  incident opened
09:44  TLS handshake failed
09:46  successful check
09:47  recovery confirmed
09:47  incident closed

Alert policy

The current development implementation creates a default in-app alert policy. Delivery records are deduplicated around the incident lifecycle so one incident gets an open notification and a recovery notification rather than one delivery per check.

Fleet-wide noise control

Large incidents can affect many related sites. Web Fleet should eventually help operators recognize correlated failures rather than flooding them with hundreds of identical alerts.

Notification transports

The first transport is the in-app dashboard. Email, chat and webhook transports remain later integration work and will need retry history, explicit failure state and secret redaction.