Uptime Basics sends availability alerts for confirmed state changes, not for every check. A Down notification follows a confirmed outage, and a recovery notification follows the transition back to Up.
When a Down alert is queued
A Down alert can be queued when:
- The monitor is active.
- A failed check cycle is confirmed by at least two of three monitoring regions.
- Three confirmed failed cycles occur consecutively.
- The monitor changes to Down and opens an availability incident.
- The monitor and account both have an eligible alert channel and verified destination enabled.
A single failed row in Detailed Logs does not send a Down alert.
When a recovery alert is queued
After a monitor is Down, one effective successful availability cycle changes it to Up, resolves the incident, and can queue a recovery alert.
The first successful result for a brand-new monitor changes Unknown to Up but does not send a recovery alert. Recovery notifications are reserved for monitors that were previously Down.
A continuous outage does not generate the same Down alert on every check because the monitor remains in the same state.
Who receives the alert
Availability notifications use the monitor's saved settings and the account's verified destination list:
- Account > Alerts provides verified destinations and defaults for new monitors.
- The individual monitor's Alert Channels settings control whether that monitor uses email or SMS and which verified destination is selected.
If the monitor disables a channel, that channel does not receive the state-change notification. SMS delivery also requires a supported verified Canadian or US phone number and available monthly SMS segments.
What the notification contains
Down and recovery messages identify the monitor and status. When available, they also include:
- Monitored URL.
- Event time.
- HTTP status.
- Response time.
- Failure details.
- A link to Monitor Details.
Email subjects clearly identify Down Alert or Recovery. SMS messages are kept concise and link back to the customer application.
Monitoring time and delivery time are different
The incident timestamp records when monitoring confirmed the state change. Notification delivery happens asynchronously afterward.
An alert can remain Queued briefly before changing to Delivered or Failed. Email-provider processing, mobile carriers, network conditions, and retry handling can add delay after the outage itself has been confirmed.
Why an alert may not arrive
Review these conditions:
- The monitor has not reached three consecutive region-confirmed failed cycles.
- The website recovered before the failure threshold was reached.
- Email or SMS is disabled at the account or monitor level.
- The selected destination is not verified or no longer exists.
- The monitor is paused or archived.
- A cooldown or notification-volume protection limited a repeated state change.
- The SMS allowance was reached or the destination is unsupported.
- Delivery failed after the alert was queued.
Alert History is retained for 14 days and shows recent queue and delivery information. Detailed Logs and incident history remain the authoritative places to inspect monitoring results when no notification was delivered.
Repeated state changes
To prevent noisy websites from flooding a recipient, Uptime Basics applies a 15-minute repeated-Down cooldown and a maximum of six state-change notifications per monitor in one hour. Additional account-level protections can temporarily limit repeated notifications during unusually sustained activity.
These safeguards do not rewrite check results, change incident history, or create usage overage charges.