If a monitor changed status and you didn't get an alert, work through these checks in order — most missing-alert cases come down to one of the first few.
Is the alert contact attached to this monitor? Alerts only go to contacts that are attached to the specific monitor that changed status. Open the monitor's settings and confirm the contact you expected is listed there — a contact that exists in your account but isn't attached to this monitor will never fire for it.
Is the contact Active and scoped to the right event? Each alert contact has a status (Active, Paused, or Not activated) and an event scope — Up and Down, Down only, Up only, or None. If the contact isn't Active, or is scoped to exclude the event that happened (for example, set to Down only when you expected an Up/recovery alert), nothing is sent.
Is a notification delay postponing the alert? If the monitor or contact has a “notify after X minutes” delay configured, the first Down alert doesn't fire until that many minutes have passed. If the monitor recovers before the delay elapses, no Down alert is sent at all — this doesn't apply to SSL, domain expiry, or response-time alerts, which always send immediately.
Check the channel itself. Email: check your spam/junk folder and any inbox filters. SMS or voice call: confirm the phone number on the contact is correct and verified. Slack, Microsoft Teams, Discord, webhooks, and similar integrations: confirm the webhook URL or workspace connection is still valid — a workspace can revoke or rotate a webhook URL without UptimeRobot knowing.
UptimeRobot does not retry a failed delivery, and it does not tell you when one fails. If a single delivery attempt to a channel fails — a bad webhook URL, an expired token, a disconnected number — it is not retried, and no failure e-mail, banner, or in-app notice is generated anywhere in your account. There's no delivery-failure log to check, and a broken contact is never automatically paused or removed — it stays attached and keeps failing silently on every future incident until you notice and fix it. Because of this, send yourself a test notification any time you change a contact's settings, and re-test periodically for any channel you rely on for critical alerts.
Use Test Notification to isolate the problem. A test notification is queued through the same delivery pipeline as a real alert, so a test that arrives is good evidence the channel works. A test that doesn't arrive means the channel itself is broken or misconfigured — not that something is wrong with the test. See How to Test Notifications in UptimeRobot for the steps.