Queue Backlog Alerts: An Issue When a Queue Grows Faster Than It Drains

Last verified on Nov 10, 2026.

What it catches

A queue is fine while it drains as fast as it fills. Backlog growth is the point where that stops being true: arrivals exceed what workers finish, and the line gets longer, minute after minute. It often starts quietly after a change in input or capacity:

• A worker pool shrank after a deploy and no one noticed.
• A downstream service slowed down and each job now takes longer.
• A burst of imports arrived and the queue has not recovered.
• One poison job is retried so often that it blocks the others.

Left alone, the queue keeps growing until work is dropped, expires or is delivered hours late.

Example: a queue that grows for six hours

This is an example, not output from a real project. A reports service logs the depth of its export queue every five minutes, along with how many jobs it took in and finished:

2026-11-07T06:00:00Z INFO reports queue=exports depth=42 enqueued_5m=31 finished_5m=34
2026-11-07T09:00:00Z INFO reports queue=exports depth=260 enqueued_5m=33 finished_5m=19
2026-11-07T12:00:00Z INFO reports queue=exports depth=611 enqueued_5m=30 finished_5m=17

Arrivals are steady. Finished jobs fell after something changed at about 07

• Name: Export queue growing for hours with no recovery
• Description: Jobs finished per interval fell below jobs enqueued, and queue depth has risen at every check since morning. Arrival volume is unchanged.
• Severity: high
• Component: reports

The analysis would put the cause on the finish side, and look in the same logs for what slowed the workers.

How Sazabi sets it up

You set nothing up. Queue names and depth fields differ from system to system, so the Sazabi agent reads your logs to see which queues you have, then writes and maintains sensors that watch queue depth and the gap between jobs in and jobs out. Sensors are standing questions about your logs. In plain words: "Is the export queue growing far beyond its usual size?"

A single large batch is not the same as a trend. Each queue is judged on its own, so one stuck queue does not hide behind healthy ones.

What happens after it fires

Sazabi records a signal and investigates. If the backlog is real, the issue shows what changed on the finishing side. Ask the agent in its thread whether a specific job type is the one stuck. Backlogs have an owner, so a delivery rule that sends high severity issues for the component to a shared channel or PagerDuty is a good fit.

Resolve the issue when the queue recovers. If it grows again later, that opens a new one.

What you need

Queue depth or enqueue and finish counts in your logs. Durable execution platforms such as Temporal, Inngest and Dagster have log sources, and your own workers can log depth on a timer. A runbook helps at the other end; see runbook.

Reading the issue

Compare the two rates before anything else. If arrivals rose, the queue is doing its job and capacity is short. If arrivals are steady and finishes fell, something on the worker side changed, and the question is what and when. Check the time the finish rate fell against your deploys, and look for one job that keeps failing and retrying, since a single poison job can hold up many others. The thread can answer both questions from the evidence.

What it does not cover

• How long a single job waited. That is queue wait growth.
• Jobs that were never scheduled. See missed schedules.
• Queues whose depth is never logged.
• Adding workers. Sazabi opens the issue and does not scale your system.

Issues Sazabi detects are metered, so check pricing.