Queue Wait Time Alerts: An Issue When Work Sits Longer Before It Starts

Last verified on Nov 10, 2026.

What it catches

Queue wait growth is a delay you cannot see from the outside: the work is accepted, nothing fails, and the effect arrives late. Users notice before dashboards do. Examples:

• A welcome email sent 20 minutes after sign-up.
• A webhook delivery that leaves a customer's integration out of date.
• A report that was asked for at noon and appears at one.
• A durable workflow step that sits scheduled while workers are busy.

Most of the time there is no error. The jobs finish successfully, only later than they should.

Example: the email queue falls behind

This is an example, not output from a real project. A notifier service logs when a job is queued and when a worker picks it up:

2026-11-05T10:00:03Z INFO notifier job=send_welcome_email id=j_88121 event=queued
2026-11-05T10:00:04Z INFO notifier job=send_welcome_email id=j_88121 event=started wait_ms=1100
2026-11-05T10:02:41Z INFO notifier job=send_welcome_email id=j_88377 event=queued
2026-11-05T10:03:02Z INFO notifier job=send_invoice_pdf id=j_88380 event=queued
2026-11-05T10:03:02Z INFO notifier job=send_invoice_pdf id=j_88380 event=started wait_ms=300
2026-11-05T10:09:50Z INFO notifier job=send_welcome_email id=j_88377 event=started wait_ms=429000

The welcome email job went from about a second to seven minutes while the invoice job stayed instant. An example issue:

• Name: send_welcome_email jobs waiting minutes to start
• Description: Time from queued to started for send_welcome_email is far above its usual level. send_invoice_pdf is unaffected, so the delay is specific to one job type.
• Severity: high
• Component: notifier

The analysis can then point at what differs, for instance a single worker pool shared with a heavy job.

How Sazabi sets it up

You set nothing up. Your job names and event fields are specific to your system, so the Sazabi agent reads your logs, finds what the queues look like, and sets up and maintains sensors that fit.

The question would be phrased something like: "Tell me when the time a job waits before starting goes far above its usual level." Each job type is judged on its own. A nightly batch that always clogs the queue at 02

Sensors are not something you write or tune. If you want a specific one, ask support in plain words.

How you hear about it

When a sensor fires, Sazabi starts an investigation and opens an issue only if the delay is real. The thread lets you ask which worker or tenant held the queue up. Shared Slack or Microsoft Teams channels can receive it through delivery rules on severity or owning team. A growing wait on a payments queue and on a marketing queue do not need the same audience.

What you need

Job lifecycle lines in your logs. If you run jobs on a durable execution platform, the logs from Inngest, Temporal or Trigger.dev can carry this. Otherwise your own worker logs will do. The on-call glossary entry covers who should receive it.

Reading the issue

Wait time has three usual explanations: too few workers, workers that are busy with something heavy, or workers that are stuck. The evidence tells them apart. If every job type waits, suspect capacity or a shared dependency. If one type waits while others start at once, suspect a worker pool or a concurrency limit that applies to that type alone. Ask the agent in the thread to compare start times across job types for the window, and to say when the delay began.

What it does not cover

• How many jobs are waiting. See backlog growth.
• Jobs that never ran at all, which is a missed schedule.
• Queues that write no timestamps or ids, so a wait cannot be told.
• Fixing the queue. The issue describes the delay and what the agent found.

Issues Sazabi detects are metered, so check pricing.