Setting Up Monitor Alerts
Alerts notify you immediately when a monitor detects a problem, so you can respond quickly before users notice.

How Alerts Work
- Your monitor runs a check
- If the check fails, a “down” alert is triggered
- You receive a notification through your chosen channels
- When the service recovers, a “recovery” alert is sent
Configuring Alerts for a Monitor
When creating or editing a monitor:
- Find the Notifications section
- Select which notification channels should receive alerts
- Choose what events trigger alerts:
- On failure - When the service goes down
- On recovery - When the service comes back up
- Save your monitor
Notification Channels
Alerts can be sent through:
| Channel | Description |
|---|---|
| Sent to your account email or team members | |
| SMS | Text message (availability depends on plan) |
| Webhook | HTTP POST to your own system |
| Slack | Message to a Slack channel |
| Discord | Message to a Discord channel |
Set up channels in Notification Channels settings.
Alert Thresholds
Configure when alerts should trigger:
Confirmation Threshold
Wait for multiple failed checks before alerting:
| Setting | Use Case |
|---|---|
| 1 failure | Critical services - alert immediately |
| 2-3 failures | Reduce false alarms from brief issues |
| 5+ failures | Low-priority services |
This helps avoid alerts from momentary network blips.
Recovery Threshold
Wait for multiple successful checks before sending recovery:
- Prevents “flapping” alerts (up-down-up-down)
- Confirms the service is truly stable again
Avoiding False Positives
False alarms waste time and cause alert fatigue. Here’s how to minimize them:
| Strategy | Why It Helps |
|---|---|
| Use multiple locations | Single-location network issues won’t trigger alerts |
| Set confirmation threshold | Brief outages don’t cause alarms |
| Check the right endpoint | Don’t monitor maintenance pages |
| Set realistic timeouts | Slow responses aren’t always “down” |
Alert Content
Each alert includes:
- Monitor name - Which service is affected
- Status - Down or recovered
- Timestamp - When it happened
- Location - Which region detected the issue
- Response details - Error message or status code
Testing Alerts
Before relying on alerts:
- Go to your notification channel settings
- Click Send Test to verify it works
- Check that you receive the test notification
- Confirm the format and content look right
Best Practices
| Do | Don’t |
|---|---|
| Set up multiple channels for critical services | Rely on a single notification method |
| Test your alerts regularly | Assume they’re working |
| Use escalation (email first, then SMS) | Alert on every channel for minor issues |
| Review and tune thresholds | Keep defaults if they cause too many alerts |