Alerts or integrations are not delivering

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
• Create alerts
• Handle incidents and on-call