Debug a slow Sume job with GET /v1/jobs/:id/events

A slow Sume job is queued, running, or waiting on your webhook. The events timeline separates them: job.queued, job.started, terminal, webhook.delivery.

5 min readSume
All posts

To find out why a Sume job is slow, read GET /v1/jobs/:id/events. The public timeline shows whether the time went to waiting in the queue, running, or delivering your webhook. Read it for the one job in question; it is a pull snapshot, not a stream.

Events and what they mean

The docs list the public events. Provider task ids and raw provider URLs are never exposed in them.

Public job events (read 2026-10-03)
EventWhat it tells you
job.createdThe request was accepted and a job exists
job.queuedWaiting for a concurrency slot; normal
job.startedA worker moved it to processing
generation.submittedWork was handed to generation
job.completed, job.failed, job.canceledThe terminal outcome
webhook.deliveryA delivery attempt to your URL

Reading the gaps

A long gap from created to started means queue pressure: concurrency is plan-based, and more jobs than slots wait as queued by design. A long gap from started to terminal is generation time. A terminal event followed by repeated webhook.delivery entries means your endpoint is slow or failing, since each attempt times out at 10 seconds.

What to do next

For queue pressure, check generation_limits on submit responses and pace submits. For delivery trouble, check your handler and use redeliver. There is no SSE stream, so do not wait on this endpoint; poll status and read events when something looks off.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume