A downstream system is broken — pause and resume a listener
Symptom: A dependency your service relies on — a third-party API, a database, another internal service — is down or degraded. Messages arriving on one of your queues can't be processed successfully, so they fail, retry, and eventually land in the dead letter queue. You'd rather stop consuming from that queue entirely until the dependency recovers, leaving the messages safely on the broker, then resume where you left off.
This is exactly what pausing a receiving endpoint is for.
What pausing a listener does
Pausing a listener stops the application from pulling messages off that endpoint. The messages stay queued on the broker (RabbitMQ, Azure Service Bus, Amazon SQS, a database queue, …) — nothing is lost, nothing is dead-lettered for a reason that isn't really about the message. When you resume, consumption picks back up from the broker.
CritterWatch pauses the endpoint across the entire application — every node stops consuming from it, and the pause is durable: a node that restarts (or a new node that joins the cluster) while the endpoint is paused stays paused until you explicitly resume. You don't have to chase individual nodes.
Pause vs. Drain
Pause stops accepting new messages immediately. Drain stops accepting new messages but lets any envelopes already in flight finish first — use Drain ahead of a planned deploy, Pause when a dependency has just failed and you want to stop now. See Listeners & Endpoints for the full control reference.
Step 1 — Find the endpoint
Open Services → (your service) → Endpoints, or the Listeners & Endpoints view. Locate the receiving endpoint bound to the affected queue. The grid shows each endpoint's status, queued count, last activity, and broker queue depth.
Step 2 — Pause it
Select the endpoint and choose Pause. The endpoint's status moves to a paused/latched state across the application, and the broker queue depth will start to climb as producers keep sending while you've stopped consuming — that's expected and safe.
You can also pause from the MCP tools (PauseListener) or the CLI, which is handy for runbooks and automation.
Step 3 — Confirm on the timeline
The pause is recorded on the Activity Timeline as a Listener event, attributed to the endpoint, with the time it happened. This gives you (and your teammates) an audit trail: who paused what, and when. When you resume later, that's recorded too — so the timeline shows the full outage-handling window at a glance.
Step 4 — Resume when the dependency recovers
Once the downstream system is healthy again, select the endpoint and choose Resume (RestartListener). Consumption restarts on every node, the backlog that accumulated on the broker drains down, and the resume is recorded on the timeline. Watch the queue depth fall back toward zero and last-activity timestamps go current to confirm the endpoint is healthy.
Related
- Listeners & Endpoints — full reference for the endpoint controls
- Inbound Commands —
PauseListener/RestartListener/DrainListenerAPI - Activity Timeline — where pause/resume events are recorded
- Dead Letter Queue — if messages did fail before you paused, replay them here once the dependency is back