Alert History records notification processing separately from checks and incidents. A delivery state explains what happened to the message; it does not change the underlying monitoring result.
Delivery-state reference
| State | Meaning |
|---|---|
| Queued | Uptime Basics created the notification record and is waiting for delivery processing. |
| Sending | A delivery worker has claimed the notification and is contacting the provider. |
| Sent | The email provider accepted the message for delivery. |
| Delivered | The provider reported successful delivery to the receiving mail system, or the SMS provider accepted the message. |
| Delayed | The email provider reported a temporary delivery delay and can continue trying. |
| Failed | Delivery could not be completed after a processing attempt. |
| Bounced | The receiving email system rejected or returned the message. |
| Rejected | The provider rejected the message before normal delivery. |
| Complaint reported | The recipient or mailbox provider marked the email as unwanted. |
| Suppressed | A delivery rule intentionally prevented the message from being sent, such as an exhausted SMS allowance, unsupported destination, cooldown, or provider-recorded SMS opt-out. |
| SMS unavailable | SMS delivery was not available for that queued notification. |
What Delivered does and does not guarantee
For email, Delivered means the provider reported delivery to the receiving mail server. It does not guarantee that the message appeared in the inbox rather than spam, a filtered folder, or a mailbox rule.
For SMS, provider acceptance does not guarantee that a specific handset displayed the message. Mobile carrier filtering, device state, roaming, and number settings can still affect the final result.
Why an alert can be suppressed
Suppression is intentional protection rather than a monitoring failure. It can occur because of:
- Alert cooldown or duplicate-notification protection.
- A state-change volume limit.
- Account-level automatic protection.
- An exhausted SMS segment allowance.
- An unsupported SMS destination.
- Another safety or channel-delivery rule.
The check and incident records remain available even when a notification is suppressed.
If a notification fails or bounces
- Confirm the destination is correct and still verified.
- Send a test alert from the monitor.
- For email, check spam, mailbox rules, storage limits, and allowlisting.
- For SMS, confirm the country, number, monthly allowance, and carrier service.
- Review the dashboard for a service notice.
- Use incident history and Detailed Logs to confirm what monitoring detected.
Repeated email bounces or complaints can affect future delivery. Remove an address you no longer control and verify a replacement before selecting it on monitors.
Monitoring timestamps and delivery timestamps differ
The check or incident timestamp records when monitoring observed or confirmed the condition. Alert delivery is asynchronous, so Queued, Sent, or Delivered can appear later.
An alert remaining queued briefly does not move the incident start time. Likewise, a failed notification does not erase the incident.
Retention
Alert History is retained for 14 days. Incident history lasts for the life of the monitor, while raw checks follow their separate retention period. Use incident history for long-term outage records rather than relying on notification history alone.