A destination says it is not delivering

If one of your alert destinations stops accepting messages, InfraNest flags it so you can fix the problem (or, in some cases, so you know there's nothing to fix). This article explains what the warning means and how to clear it.

#Overview

• Not delivering means InfraNest tried to send alerts to that destination and the service turned them away.
• Nothing is lost — each alert is emailed to you right away and also saved so you can catch up later.
• InfraNest keeps trying in the background, so a destination can start working again on its own.
• The warning only shows up after more than one failed send, so a single blip at Slack or Discord won't trigger it.

#Understand the warning colour

The colour tells you whether there's anything for you to do.

Red — something needs your attention. The service has refused the credentials for this destination. This usually means a webhook URL or key was revoked, regenerated somewhere else, or pasted incorrectly. It will not fix itself.

Amber — nothing to do. The service is having its own issues, or asking InfraNest to slow down. InfraNest keeps sending, and the warning clears automatically once a message gets through.

#Fix a red warning

1. Go to Alerts → Destinations and open the destination.
2. Paste a fresh webhook URL or key. The setup guide for your service shows you where to find one.
3. Select Send test.

The warning clears as soon as one message gets through, so a successful test confirms it's fixed. If the test fails, the message beneath it explains what the service replied.

NoteTest failed or Test sent successfully will appear depending on the result, along with details like Last test delivered {ago} or Last test failed {ago}.

#Recover missed alerts

Once the destination is working again, its card on Alerts → Destinations shows how many alerts it missed, with two choices:

1. Select Send them here now to deliver everything it missed as a single message, listing each alert and when it happened.
2. Or select Discard to drop the missed alerts without sending them. Since they were already emailed to you, nothing is lost either way.

Missed alerts are kept for 7 days. The exception is PagerDuty: its missed alerts are emailed but never sent later, since paging someone now about last night's issue would wake them for nothing.

#Who gets notified

• A personal destination (one you added for yourself) notifies you.
• A shared destination notifies the workspace's owners and admins.

Those same people receive the destination's alerts by email while it isn't delivering, plus an in-app notification and an email about the problem itself. If it stays broken, you'll be reminded again on a widening schedule — at most once a day, never per failed alert. Once it's fixed, you get one message confirming it.

NoteThe email about a broken destination never goes through that same destination — so a dead Slack webhook is never announced to you via Slack.

#Catch problems early

A destination can only show Not delivering once it has turned away an alert — so one with nothing to send won't show a warning at all. Turn on Monthly test on its card under Alerts → Destinations to send it a test message every month, catching problems on a quiet day. Since Email and Microsoft Teams can't confirm whether someone read the test, that message includes an I got it link to confirm receipt.

#Good to know

• A disabled destination is different — nothing is being sent to it, so it can't fail.
• The same warning colour appears on the destination's own page and on the Integrations hub, so a struggling destination is never shown as healthy anywhere.
• The Activity tab lists every delivery attempt and its result, if you want more detail. An alert that was emailed instead shows an amber envelope next to the destination — hover it to see who received it.
• If you already receive an alert by email (through an email destination, or because you get monitor emails), you won't get a duplicate copy just because another destination rejected it.