How-to guide

Operational runbook: a target went down

When a receiver fails, follow the issue from the first alert to a verified recovery: notify → investigate → verify → resume. Use the console yourself or connect an agent to help investigate.

Two kinds of target trouble
Probing — a transient outage; the circuit is open and Queuey is auto-probing to recover. It resumes on its own, no action needed. Requires action — a sticky failure (e.g. auth rejected); the queue holds and waits for you to fix the target and resume. Knowing which is which is half the job.

Set up notifications

Open Notification destinations on your license page in the console. Add an email address or a Slack incoming webhook, choose the minimum severity and save. Use Send test and check that the alert arrives at the intended destination.

To notify an agent, choose an agent destination where that option is available. Queuey supports a signed webhook to your own HTTPS endpoint or a Claude Code routine. The setup guide in the console walks through the connection. Start with Lasting delivery problemsto focus the agent on issues that persist or get worse.

A notification starts the investigation. Access to Queuey is configured separately through MCP. Give the agent the access its job needs; the console's routine guide starts with Investigate (read and suggest). Connecting MCP by itself does not subscribe the agent to alerts.

Example: your receiver starts returning 401

  1. Queuey holds deliveries and raises an issue because the receiver rejected its credentials.
  2. When the issue matches your notification settings, Queuey alerts your team or starts the connected agent.
  3. The agent reads the issue and delivery evidence through MCP, checks the application context it has access to, and records its findings on the issue.
  4. Correct the credentials, then verify that a delivery reaches the receiver. Apply any required production approval before changing Queuey.
  5. Resume held deliveries and replay failed events as needed. Check the outcome and leave a note explaining the fix.

Test both parts: an alert reaching the agent, and the agent successfully reading the issue. A successful test notification alone does not prove the agent has the right Queuey permissions.

Investigate and recover

  1. 1 — See what's wrong

    When a target stops accepting deliveries, Queuey surfaces it as an issue on the queue with a target-health state, instead of silently burning retries. The events pile up as held rather than lost.

  2. 2 — Read the diagnosis

    Each issue carries a rule-based diagnosis (and an incident report) explaining what failed and why — the status codes, the failure class, when it started. You don't reverse-engineer it from raw logs.

  3. 3 — Fix the target, then clear & resume

    Once the endpoint is healthy again, clear the requires-action lock to resume the queue. Held events flow again from where they stopped — in order, for ordered queues.

  4. 4 — Replay what failed

    Events that exhausted their retries are in the dead-letter queue. Inspect them, then replay — a single event, or the whole filtered set in bulk — once the underlying cause is fixed.

  5. 5 — Close it out

    Resolving the issue produces an after-action summary, so the next person (or the next incident) starts with context instead of a cold trail.

Why this matters

The issue, delivery history and recovery steps stay together. Your team and your agent can see what failed, what has been checked and which events still need to be delivered.

Related