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.

Your agent inspects alerts. A person tests a notification channel and repairs a connection in the Console.

Ask your agent

"Is the rule checkout-errors enabled? Is its alert firing now? Are any silences active?"

"List the delivery receipts for that alert and tell me which channel failed."

Job	MCP tool or action	CLI command
Read a rule and its state	list_alert_rules, get_alert_rule	anectico alerts rules list, anectico alerts rules get
Validate a rule and preview its query	test_alert_rule (read action)	anectico alerts rules test
List firing alerts	get_active_alerts	anectico alerts list
Read the silences in effect	list_alert_rules (lists them), get_silence (read action)	anectico alerts silences list
Read delivery receipts	list_notification_deliveries, get_notification_delivery (read actions)	anectico deliveries list, anectico deliveries get
Read who is on call	resolve_oncall (read action)	anectico oncall now
Read a notification channel	list_notification_channels, get_notification_channel (read actions)	anectico channels list, anectico channels get

Reads need mcp:read and the matching scope, for example alerts:read, alerts:rules:read or channels:read. An alert has no proof page. Its delivery receipts and its history are the record.

Check the alert state

1. Ask your agent to 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. Ask your agent to confirm that the alert is firing (get_active_alerts, or anectico alerts list).
5. Check active silences and deduplication before changing the rule.

Use the rule's test action (test_alert_rule, or anectico alerts rules test) for configuration validation, but do not treat a test notification as proof that the production condition can fire.

Check the delivery path

In the Console, open Connections and notifications (/connections) and choose the Notifications tab. Find the exact routed channel and choose Test. Your agent can send the same test with test_notification_channel or anectico channels test <channel-id>. If it fails:

• verify the destination, webhook, email, or routing key;
• on the Connections tab, resolve Needs reauth (or Reinstall needed) 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 channel type needs a connected integration and none was found	Connect the provider under Connections first.
The endpoint rejected the test	The destination answered and refused. The reason includes the HTTP status code it returned.
The test message could not be delivered	No answer came back from the destination. Work through the checklist below.

A test delivery has three outcomes: it was delivered, the destination answered and refused, or no answer came back. When the destination answers and refuses, the reason carries its HTTP status code and nothing else from its response.

"Could not be delivered" is deliberately one reason. It covers every way of getting no answer, and Anectico does not say which one applied. Check each of these yourself:

• the hostname is spelled correctly and resolves in public DNS;
• the destination is a publicly routable address — private, loopback, link-local and cloud-metadata addresses are never delivered to;
• the destination accepts connections on the port in the URL and answers promptly;
• its TLS certificate is valid for the hostname and issued by a public authority; and
• it answers directly rather than redirecting — redirects are not followed.

A delivery in the notification history that got no answer shows the same single reason.

The reasons never contain a provider's raw error text or any part of the stored channel configuration.

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

Check on-call routing

Ask your agent to confirm that the current schedule has an active responder (resolve_oncall), that the escalation policy references that schedule (list_escalation_policies, or anectico escalation get <policy-id>), and that the responder has a valid personal contact method. A person manages their own contact methods in the Console, on the Notifications tab of Connections and notifications. 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