Add an alert to a monitor

An integration stores a connection or recipient. An alert rule attaches that connection to one monitor and one Event. Connecting Slack, Telegram, or a webhook alone does not enable incident notifications for every monitor.

Last checked: 2026-10-09 · Maintainer: UptimeObserver Support

Before you begin

• Create a monitor in your account.
• Configure and test a notification integration.
• Check plan availability, including the known Free Email/Free Mobile setup restrictions.
• Decide who should receive Monitor Down and Monitor Up notifications.

Add the down rule

1. Open Monitoring → Monitors and select the monitor.
2. On Monitor Details, click Add Alert in the header.
3. Select an Alert Type from the table below.
4. Set Event to Monitor Down and select the integration-specific target.
5. Leave Re-send alert while incident is active off for your first setup. On paid plans, it can repeat Down notifications; it does not perform extra checks. See Alert retrigger.
6. Click Save changes. Open the Alerts tab and confirm the new rule appears under Alert Notifications, with its status switch active and the intended event and target.

Connection	Alert Type	Target to choose
Email	Email	One Email Settings configuration per rule
Slack	Slack	An authorized Slack Channel
Discord	Discord	A saved Discord configuration
Telegram	Telegram	Uses the account's connected Telegram chat; no target selector
Free Mobile	Free Mobile	A saved Free Mobile configuration
Pushover	Pushover	Pushover Account and priority; start with Normal
PagerDuty	PagerDuty	The service authorized during connection
Webhooks, Ntfy, Zenduty, Twilio SMS, or Twilio WhatsApp	Webhook	The saved webhook designed for the selected event

For Pushover Emergency, also configure its retry interval and expiry; it cannot be combined with alert retrigger. See Emergency alerts.

Add the recovery rule

Repeat the workflow with Event → Monitor Up. This is a separate rule; one rule cannot subscribe to both events.

• Use the same recipient or service if it should see both notifications.
• For webhook-based integrations, select the resolution/recovery webhook, not the Down payload. Follow the integration's payload setup guide.
• For PagerDuty, use the same service for both rules so recovery can resolve the corresponding incident.
• For multiple email recipients, add a rule for each Email Settings configuration and each event. The creation form's multi-recipient selection is different from the single-recipient Add Alert modal.

If rules were already added during monitor creation, inspect the list first rather than create duplicates. Duplicate active rules can send duplicate notifications.

Verify delivery

Connection test

Use the test action on the integration's settings page, where provided, and confirm receipt on the actual device, channel, or inbox. Check spam filters, quiet hours, and the provider's delivery logs.

The test checks the saved connection. It does not verify your monitor's event selection, rule activation, or retry threshold. The Send test alert action in the monitor's alert list is currently disabled; use the integration test instead. PagerDuty can be verified with the end-to-end test below.

End-to-end down and recovery test

Use a dedicated test endpoint

Do not stop a production service to test notifications. These tests send real alerts, can page on-call staff, and may incur SMS/WhatsApp charges. Tell the intended recipients first and use a test service in incident-management integrations.

1. Create a separate HTTP(S) monitor for a publicly reachable endpoint you control. Use one region, Retries = 0, a normal check interval, and 2xx as the accepted status group. Make sure no maintenance window covers it.
2. Attach active Down and Up rules using a test recipient/service. Confirm the endpoint returns 200 and the monitor records Up.
3. Make the endpoint return 500. Wait for the next check and event processing; confirm the monitor shows Down, an incident appears, and the Down notification arrives.
4. Restore 200. Wait for the next successful check and event processing; confirm Up, a resolved incident, and the recovery notification. See multi-region recovery before repeating this with several regions.
5. Remove or pause the test monitor when finished. If the test was interrupted, restore the endpoint first.

For Heartbeat, test missing pings and resumed successful pings instead; success: false still counts as a ping. Follow the heartbeat behavior.

If tests work but incident alerts do not

• Confirm both rules are active on the right monitor, with the intended event and target.
• Check whether the monitor is Retry, not yet Down, or is Paused. See the monitor lifecycle.
• Check maintenance coverage. For repeated reminders, check the incident's Alert Snooze state; snooze affects retrigger notifications.
• For webhooks, verify you selected the correct Down/recovery payload. A generic webhook test uses sample data.
• Check provider filters, delivery failures, permissions, and plan availability.

For support, include the monitor ID, event, alert type, incident ID if available, timestamp with time zone, and whether the integration test arrived. Redact credentials and secret URLs.

Edit, deactivate, or remove a rule

In the monitor's Alerts → Alert Notifications list:

• Use Edit alert to change an event or target.
• Use the status switch to deactivate one rule without deleting it or pausing monitoring.
• Use Delete alert to remove a rule.

These actions affect that rule, not every monitor using the integration. Removing the underlying integration is a different operation and can affect all rules that reference it.