Configure alerts and delivery routing
Choose incident rules, contact points, routing filters, and quiet hours.
Before you begin
Members can view incidents for their accessible servers. Owners and admins configure rules, contact points, routing, and delivery settings.
Open Alerts. Its tabs are Active, History, Rules, Routing, and Contact points.
Set the built-in incident rules
Open Rules and review:
| Control | Default | Meaning |
|---|---|---|
| Firing delay | 60 seconds | Grace period before an offline incident notifies |
| Disconnect threshold | 3 | Disconnect count used to detect flapping |
| Evaluation window | 900 seconds | Window for the disconnect count |
| Notify when resolved | On | Send a recovery notification |
Change the values to fit your operational needs and save them. The allowed firing delay is 30 to 900 seconds. The disconnect threshold is 2 to 10, within a 120 to 3600-second evaluation window.
These rules concern offline and flapping-server incidents. Do not assume they configure arbitrary TPS or CPU thresholds.
Add a contact point
- Open Contact points.
- Enter a recognizable Name.
- Choose Type: email, webhook, Discord, or chat.
- Set Target to an email, HTTPS endpoint, or active server-scoped chat channel.
- Enable and create the contact point.
Keep webhook URLs private. A chat destination must use an active channel associated with a server.
Create a routing policy
- Open Routing and name the policy.
- Select its Server scope and the event kinds or severities to match.
- Select at least one enabled contact point.
- If needed, set both quiet-hour Start and End, plus Timezone.
- Enable and create the policy.
Empty event-kind or severity filters match all values. Chat contact points must match the routing policy's server scope. A destination alone does not establish routing.
Verify delivery
Review Active or History for a relevant incident. In the routing delivery history, inspect the destination, status, HTTP response status, and error.
Use a planned test server outage if you need an end-to-end check. Wait beyond the firing delay and confirm a delivery, then reconnect and check the recovery behavior.
If no notification arrives
Check whether an incident exists, the firing delay elapsed, the policy matches its server and event, and both the policy and contact point are enabled. Check quiet hours before retrying a destination.
A recorded delivery failure needs destination-side investigation. A missing incident needs agent or rule investigation. For personal preferences, use My notifications.
Was this page helpful?
Send a quick note if anything is missing or unclear.
Last updated on