Alerts & triggers
Beyond notifying end users, you'll want your team to know the moment something breaks.
Per-monitor alerts
Each monitor can have alerting configured so that a change of state (for example UP → DOWN)
raises a notification. Typical options include:
- Confirmation threshold — require N consecutive failing checks before alerting, to avoid flapping on a single blip.
- Recovery — notify again when the monitor returns to
UP.
Triggers (notification channels)
Triggers define where alerts go. Configure them under Triggers in the console, then attach them to monitors. Common uses:
- Email your on-call address or a team distribution list.
- Webhook to a chat or incident tool, so alerts land where your team already works.
Recommended setup
- Create a trigger for your team's channel (email or webhook).
- Attach it to your important monitors.
- Set a confirmation threshold (e.g. 2–3 failures) to cut false alarms.
- Test it by temporarily pointing a monitor at an unreachable target.
Note
Alerts (to your team) are distinct from subscribers (your users). You typically want tighter, faster alerts internally and clear, human updates externally.
Tip
Pair alerts with external alert ingest so alerts from other systems can also open incidents on your status page automatically.