Troubleshooting: Not Receiving Alerts

Work through this in order. The first step answers the single most important question, which is whether we sent the alert at all, and the answer decides which half of the article you need.

Step 1: Check the delivery log

Open Settings → Alerts, then Manage on the destination in question. The delivery log lists every attempt with its timestamp, the alert type, the HTTP status and the response.

If the alert is in the log with a successful result, we sent it and the receiving end lost it. Skip to "The alert was sent but never arrived".

If the alert is in the log as failed, the status code tells you why; see the table below.

If the alert is not in the log at all, we never tried. Continue to step 2.

The delivery log applies to webhook, Slack and Discord destinations. Email delivery is not logged per message, so for email use the domain's own activity history to establish whether the underlying event fired.

What the failure statuses mean

Failed deliveries are retried for up to 6 hours. Any delivery in the log can also be replayed manually once the receiving end is healthy.

Step 2: Is the destination enabled?

A disabled destination shows greyed out in the Alerts tab with a status dot instead of a green one, and it delivers nothing.

Destinations disable themselves after 20 consecutive failures, which is why one that used to work can stop. When that happens the row shows the reason. Fix the underlying endpoint, then re-enable the toggle; the failure counter resets on the first success.

If the row shows a consecutive-failure count but is still enabled, you are watching a destination on its way to being disabled. Treat that as the warning it is.

Step 3: Is the destination verified?

An email destination must prove ownership of the address before it delivers. An unverified address is skipped silently by design, because sending alerts to an unproven inbox is how you leak a domain portfolio to whoever typo'd their way into it.

This catches people out in one specific case: changing your account email address. The email destination follows the new address and its verification is reset, exactly like your account's own email verification. Until you click the link, no alerts are emailed. Check your inbox for the confirmation.

Step 4: Check the alert-type filter

Each destination carries its own list of alert types it accepts. An alert of a type not on that list is not a failure and does not appear in the delivery log, because nothing was attempted.

Open Manage on the destination and confirm the type you are waiting for is selected. If you set up separate Slack and email destinations to split urgent from routine, this is the likeliest explanation, and it usually means one type ended up on neither list.

Step 5: Is the domain actually being monitored for this?

• Monitoring is on for the domain. If its toggle is off, nothing is checked and nothing can fire.
• The check type is on. SSL alerts need SSL monitoring enabled for that domain; DNS alerts need DNS monitoring.
• The domain is in your Portfolio. SSL monitoring, DNS monitoring and expiry reminders are portfolio features. A watchlist domain gets availability and status change alerts only.
• Your plan covers it. SSL and DNS monitoring, and every delivery channel except email, require an active paid subscription. If a subscription lapsed, these stop, and that is a common cause of "it used to work".
• The check has not auto-paused. After sustained failures a check type pauses itself for that domain and sends a monitoring.auto_paused alert. The domain's page shows the paused state.

Step 6: Did the event actually happen?

Open the domain's page and look at its activity history. It records every check, whether or not anything changed.

• The check ran and found no change. Then there was nothing to alert about. Registry data lags reality, sometimes by hours; a domain you can see is available at a registrar may not yet be published as available in WHOIS or RDAP.
• You already had this alert. Each alert fires once per occurrence. A condition that persists, such as a domain sitting in redemption for weeks, alerts once when it starts and not again while it continues. See how to customize alert frequency.
• The check has not run yet. Check frequency depends on the domain's urgency and your plan. A quiet registered domain is not checked every few minutes.

If the missing alert was an SSL one

Certificate alerts have three failure modes of their own, on top of everything above.

• No reminder windows are selected. SSL reminders fire at the windows you choose, and choosing none means there is nothing to send in advance. Set them on the domain's page; 90, 60 and 30 days is a reasonable default.
• The certificate expired before a window could fire. You will get the "certificate is invalid" alert, but the pre-expiry warnings no longer had time to happen. This is the usual explanation for "it only told me once it was already broken".
• We could not reach the server. If the host was offline, firewalled or pointing somewhere unresolvable at check time, there was no certificate to read. That is recorded as a failed check, not as a certificate problem, and repeated failures auto-pause the check (step 5).

If instead the alert arrived but disagreed with reality — you renewed and it still says expired — that is How to fix an expired certificate, which covers why a renewed certificate is often not the one your server is serving.

The alert was sent but never arrived

For email, in this order:

1. Spam and junk folders, including any server-side quarantine your provider runs before the mailbox.
2. Allowlist [email protected]. Corporate filters are the most common cause of consistently missing alerts, and they typically discard silently.
3. Filters and rules in your client. A rule matching on "domain" or "expiry" will catch these.
4. Confirm the address itself is the one you expect, in your profile.

For Slack, the message goes to the channel that was chosen when the webhook was created, and it does not follow renames or move if that channel is archived. A 200 in the log with nothing visible almost always means it is landing in a channel you are no longer looking at.

For Discord, the same applies, and check the channel's permissions have not changed since you created the webhook.

Confirm the whole path in one step

Use Send test from the destination's Manage panel. It sends a real alert down the real delivery path and records the result in the log, so it exercises everything except the monitoring that would have triggered it.

• Test arrives: the destination is fine. Your issue is upstream, in steps 4 to 6.
• Test fails in the log: the destination is the problem, and the status code names it.

Still stuck?

Contact support with the domain name, the alert type you expected, the approximate time you expected it, and what the delivery log shows. Those four things let us trace the exact event on our side rather than starting over.

Related

• Types of alerts we send
• Alert delivery channels overview
• Webhook payloads and signature verification
• How to customize alert frequency