# Alerts or integrations are not delivering

> Trace a missing notification from rule evaluation through channel, connection, and on-call routing.

Canonical page: https://anectico.com/docs/help/alerts-and-connections/


Treat evaluation and delivery as separate stages. A healthy connection does not prove a rule fired,
and a firing alert does not prove its destination is configured.

## Check the alert state

1. Confirm the rule is enabled and uses the intended project and environment.
2. Re-run the query or condition over the same window.
3. Check threshold, sustained duration, and no-data behavior.
4. Confirm the alert appears as firing in **Alerts**.
5. Check active silences and deduplication before changing the rule.

Use the rule's test action for configuration validation, but do not treat a test notification as
proof that the production condition can fire.

## Check the delivery path

Open **Settings → Notifications**, find the exact routed channel, and choose **Test**. If it fails:

- verify the destination, webhook, email, or routing key;
- open **Connections** and resolve **Needs reauth** or revoked provider access;
- confirm the destination channel or project still exists in the provider; and
- check provider-side permissions and delivery logs.

### Read the failure reason

A failed test returns one of a fixed set of plain-language reasons. Each names the class of failure
and the part of the configuration it belongs to, which is enough to choose the next step:

| The reason says | What to do |
| --- | --- |
| The channel type cannot be tested | This channel type has no test send. Verify it by triggering a real delivery. |
| The configuration could not be decoded, or is incomplete or invalid | Reopen the channel and correct the fields it requires. |
| The webhook URL is not a valid `http` or `https` URL | Fix the URL. |
| The webhook host is, or resolves to, a blocked address | Point the channel at a publicly routable host. |
| The webhook host could not be resolved | Check the hostname and its DNS. |
| The channel type needs a connected integration and none was found | Connect the provider under **Connections** first. |
| The endpoint did not respond in time, or could not be reached | Check that the destination is reachable from the public internet. |
| The endpoint rejected the test | The destination answered and refused. The reason includes the status it returned. |

When the destination itself answers and refuses, the reason carries that destination's own HTTP
status code, which separates a misconfigured destination from a network problem. A blocked-address
reason names the class of address that was rejected — private, loopback, link-local, or
cloud-metadata — but deliberately not the address the host resolved to.

The reasons never contain a provider's raw error text or any part of the stored channel
configuration. If the reason is only that the delivery did not succeed, the destination failed in a
way the test could not classify; check the provider's own delivery log.

After rotating a secret or reconnecting OAuth, test the saved Anectico channel again.

## Check on-call routing

Confirm the current schedule has an active responder, the escalation policy references that schedule,
and the responder has a valid personal contact method. Overrides and time zones can change who is
currently on call.

When escalating to support, include the alert, rule, and channel IDs plus the exact UTC time. Never
include provider secrets, API keys, or session cookies.

- [Connect tools and notification delivery](/docs/manage/connections-and-notifications)
- [Create alerts](/docs/respond/alerts)
- [Handle incidents and on-call](/docs/respond/incidents-and-on-call)