# A destination says it is not delivering

> If a destination shows Not delivering, InfraNest tried to send alerts there and the service turned them away.

Source: https://infranest.io/docs/destination-not-delivering
Last updated: 2026-09-14

---

If one of your alert destinations stops receiving messages, InfraNest flags it so you can fix it before you miss something important. 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 they were turned away.
- Missed alerts are not held and delivered later — they are simply missed while the warning shows.
- InfraNest keeps trying in the background, so the destination starts working again on its own as soon as the problem is fixed.
- The warning only appears after more than one failed send, so a single hiccup at Slack or Discord won't trigger it.

## Understand the warning colour

The colour tells you whether there is anything for you to do.

- **Red — something needs your attention.** The service refused the credentials for this destination. This usually means a webhook URL or key was revoked, regenerated somewhere else, or pasted with a character missing. It will not fix itself.
- **Amber — nothing to do.** The service is returning errors on its end, or asking InfraNest to slow down. InfraNest keeps sending, and the warning clears on its own once a message gets through.

## Fix a red warning

1. Go to **Alerts**, then **Destinations**, and open the destination showing the warning.
2. Paste a fresh webhook URL or key into the destination's settings. The setup guide for your service explains where to find one.
3. Select **Send test**.

The warning clears as soon as one message gets through, so a successful test confirms the fix. If the test shows **Test failed**, the message underneath it explains what the service replied.

## Know who gets notified

Whoever owns the destination is told:

- A **personal** destination (one you added for yourself) notifies you.
- A shared destination notifies the organisation's owners and admins.

You'll get an in-app notification and an email. If the problem continues, you'll hear again on a widening schedule — at most once a day, never once per failed alert. Once it starts working again, you'll get a single message confirming it.

> [!NOTE]
> The recovery email never goes through the broken destination itself, so a dead Slack webhook is never announced to you via Slack.

## Tips

- A **Disabled** destination is different from **Alerts are not reaching this destination** — nothing is being sent to a disabled destination, so it can't fail.
- The warning also shows on the destination's own page and on the **Integrations** hub, so a destination that's refusing alerts is never shown as healthy anywhere.
- Check the **Activity** tab to see every delivery attempt and what the service returned, if you want more detail behind the warning.
