How-to guide
Operational runbook: a target went down
Delivery isn't just "send and retry" — it's something you operate. When a target fails, Queuey gives you a clear path from detect → diagnose → resume → replay, without losing events or guessing.
- 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 — 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 — 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 — 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 — 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
Most webhook tooling stops at retry-and-log. The operational layer — target-health, safe holds instead of duplicate side effects, clear & resume, and replay — is what turns "our webhooks are failing and we don't know why" into a five-minute fix. It's the difference between a delivery service and a delivery engine.
Related
- Reliable delivery — retries, idempotency, Hold-on-timeout, and DLQ.
- Core concepts — the event lifecycle and issue model.