Debug a slow Seedance job with the job events timeline

When a Seedance job looks slow, read GET /v1/jobs/:id/events before you retry. The API reference describes it as public timeline events for debugging and recovery, which is the cheapest way to see where a job is without submitting a second one.

The goal is to separate a job that is genuinely slow from one that failed quietly or was never accepted.

Which job endpoints exist?

The docs list six job reads and writes.

How long should I wait first?

The video guide says generation typically takes 30 seconds to several minutes depending on model and parameters, and that a job can stay in pending for a while under load. Poll about every 30 seconds rather than hammering the endpoint.

Some context on timing. A short 480p clip can finish in under a minute while a 30 second 1080p clip takes noticeably longer, and load on the provider side moves both. A pending status in the first minutes is normal and does not mean the request was lost.

What is the safe order of actions?

Read status, read events, then decide. Do not resubmit with a new body: that creates a second job. If you must resubmit, reuse the same Idempotency-Key only when the body is unchanged, as in the idempotency post. Cancel only works before generation starts, after which the API returns 409 job_generation_already_started.

Keep a small runbook for your team. One: confirm the job id exists with GET /v1/jobs/:id. Two: read the status. Three: read the events and note the last one and its time. Four: wait one more polling cycle. Five: if nothing moves for much longer than usual, cancel if the API still allows it, which it does only before generation starts, or contact support with the id.

This order avoids the two expensive mistakes: duplicate submits and abandoned jobs that were about to finish.

What does the docs not tell you?

The text does not list the event names or give a time after which a job is considered stuck, so I will not invent them. Treat the events as evidence for a support request, together with the job id and the time you submitted.

If you do cancel a job that has not started, check /v1/usage afterward; the docs describe refunds as ledger entries, so the reserve should come back as one.