Uptime Alert Escalation
Define who should hear about an outage, when they should hear it, and which endpoint policy controls the response.
Name the audience once
Create destinations such as DevOps Slack, Management Teams, or Stakeholder Email, verify them with a test, and reuse them across escalation policies.
Escalate as downtime persists
Every endpoint selects one named policy. Each policy can route outage steps, recovery, SSL warnings, and sustained response-time degradation without repeating destination setup on every endpoint.
| Down for | Notify | Purpose |
|---|---|---|
| 3 minutes | DevOps Teams | Start technical response |
| 15 minutes | DevOps Email | Broaden technical awareness |
| 60 minutes | Management Teams, Stakeholder Email | Escalate prolonged impact |
Example only. Downtime thresholds and destination selections are editable.
Recipient consent
A new email recipient must accept a single-use confirmation before operational alerts begin.
Test before relying on it
Each configured destination has a test action and a visible result, without exposing stored webhook secrets.
Delivery and escalation history
Review the latest 50 notification attempts and latest 50 outage escalations in their respective History tabs.
Recovery without a new audience
Recovery notifications go only to destinations that were actually reached during that outage. SiteInformant also prevents the same escalation step from firing twice for one incident, even when background processing retries.
Build the alert path before the outage
New accounts start with an Owner Email destination and a Default policy, so monitoring can begin without a blank configuration.
Try SiteInformant