Notifications
Notification channels, alert rules, and delivery for failures and recoveriesEdit
Notifications tell your team when monitors fail, jobs break, or services recover. Set up a channel, attach it to a monitor or job, and use thresholds to avoid noise.
Communicate → Notifications has two tabs: Channels, where you set up where alerts go, and Delivery history, which lists the latest 200 alert notifications sent for your monitors and jobs. Each failure alert also opens an incident, unless you turn that off in the check's Incidents settings. See How alerts become incidents.
Set Up a Channel
SlackMicrosoft TeamsDiscordTelegramWebhookEmail uses your SMTP provider; the others use the service's webhook or bot token.
Open Communicate → Notifications → Channels and select Create channel.
Pick the provider and enter its credentials (see Provider Configuration).
Select Test Connection, then save.
Test sends are rate limited per user: email tests allow 5 per 10 minutes and may only target your own address or members of your organization (at most 5 recipients); other channel types allow 20 tests per 10 minutes. A channel used by a monitor or job cannot be deleted until you remove it from them.
Select the channel in a monitor's or job's Alert Settings. Channels linked through the API appear in the monitor's Alert Settings. Saving the settings replaces the linked channels with your selection.
Alert Types
| Alert | Trigger | Severity |
|---|---|---|
| Failure | Consecutive failures reach threshold | Error |
| Recovery | Consecutive successes reach threshold after the failure threshold was reached | Success |
| SSL Expiring | Website monitor's certificate is within its warning window, has expired, or could not be read for 24 hours | Warning; at most once every 24 hours |
| SSL Renewed | A certificate you were warned about is healthy again: valid with more days left than the warning window, or a later expiry date than the one warned about | Success; once per warning |
Threshold Configuration
Thresholds prevent alert noise from transient issues like network blips or brief service hiccups.
Failure Threshold
The number of consecutive failures required before sending the first failure alert. This prevents alerts from single network blips.
Recovery Threshold
The number of consecutive healthy checks required before sending a recovery alert after the monitor was down. In the app, failure and recovery thresholds are 1–5; the API accepts 1–100. A monitor that was never down, or whose failures stayed below the failure threshold, sends no recovery alert.
SSL warnings are separate from the monitor's up/down result. Turn on SSL Check on a website monitor; Alert on SSL certificate expiration is then switched on for you (you can switch it off) and uses the monitor's Alert in N days window. A warning is sent at most once every 24 hours while the certificate stays inside the window. A single failed certificate read sends nothing. If the site stays up but its certificate can't be read for 24 hours, a warning is sent, repeated at most daily while the failure continues.
When a warning has been sent, the next check that finds a valid certificate outside the warning window (or with a later expiry date) sends one SSL certificate renewed (valid until date) notice to the same channels and appears in alert history as SSL Renewed. It is sent once for each warning, and not at all if no warning was sent. If the warning was that the certificate could not be read, the notice says SSL certificate readable again instead. Turning off SSL alerts or SSL Check discards a pending notice. The notice does not open or resolve an incident. A channel that fails is retried up to 5 times and then skipped; the notice is not sent again on later healthy reads. During a maintenance window it is held back and sent after the window. Webhook channels receive it as a resolve event with the same ssl: key as the warning.
Failure, recovery, SSL and SSL renewed notices are not sent while a scheduled maintenance window covers the monitor; checks still run and count toward uptime.
Alert limiting
At most 3 failure alerts go out per failure streak, for monitors and jobs. The first goes out when the failure threshold is reached, then come reminders. For jobs a reminder follows every further max(5, 2 × threshold) failures. For monitors the gap doubles: with N = max(5, 2 × threshold), the first reminder comes N failures after the first alert and the second 2N after that. A monitor alert that cannot be delivered is retried on the next checks for up to N checks, and the following gap is counted from when it was actually sent. Each channel normally gets an alert once. If one channel fails while others succeed, only the failed channel is retried (up to 5 attempts), and a retried check or several workers evaluating the same alert at once do not send it twice. In rare failure cases (a worker stopping in the middle of sending, a database error while recording the delivery, or while Supercheck is being upgraded) a channel can receive an alert twice, so integrations should de-duplicate on the alert's dedup key. A passing run resets the streak, and each recovery sends one alert. The interval is not configurable.
Provider Configuration
Select Email and enter recipients in the notification channel.
Notifications hide credentials in a monitor's target URL: user name and password, and values of parameters such as token, key or password, are replaced with REDACTED.
Delivery History
Review the latest 200 alert notifications in Notifications → Delivery history. Incident update notifications are not listed there. Each row shows:
| Column | Shows |
|---|---|
| Alert | Type and severity |
| Target | Monitor or job name |
| Channels | Notification channels used, and delivery status |
| Incident | The incident the alert belongs to, linked. A sent failure alert with no incident (for example, incidents turned off for that check) shows Open incident to create one. See How alerts become incidents |
| Time | When it was sent |
| Delivery metadata | For AI SRE correlation: provider type or preset, dedup key, event action, response status, attempt count and response hash when available |
Use delivery status and HTTP diagnostics to troubleshoot failed notifications. Raw provider response bodies and credential values are not displayed.