Higgsfield's Seedance outage on Sept 30: slow vs failed jobs on Sume
Higgsfield said Seedance 2.0 failed more and 2.5 ran slow on Sept 30, now fixed. On Sume, a slow job is queued or processing; rerun only after failed.

Higgsfield's changelog entry dated Sep 30, 2026 says generations failed more often than usual on Seedance 2.0 and took longer on Seedance 2.5 because of a provider-side issue, that both models were running normally again, and that failed generations could be run again. The lesson for a Sume user is to tell slow from failed. A slow job is queued or processing and keeps running; only a failed job is a reason to rerun.
The incident text is from the Higgsfield changelog, read 2026-10-02. The Sume rules are from Jobs and results. The Higgsfield entry names no other platform, so this post does not say whether any Sume job was affected.
What did Higgsfield say happened?
The entry is titled Seedance 2.0 generation failures and Seedance 2.5 delays resolved. It gives a provider-side issue as the cause, offers no timestamps or counts, and apologises for the disruption.
Because the cause is upstream, any product that sits on the same model could in principle show similar symptoms. The entry does not claim that any other service did.
| Symptom | On a Sume job | What to do |
|---|---|---|
| Generation took longer | sume_status queued or processing, terminal false | Keep polling; do not resubmit |
| Generation failed | sume_status failed, terminal true, a public error on the job | Read the error, then submit again |
| Client timed out locally | The job keeps running and still bills | Resume from status_url instead of resubmitting |
How do I tell slow from failed on Sume?
Poll GET /v1/jobs/{id}/status and read data.terminal and data.sume_status. The docs list five statuses: queued, processing, completed, failed and canceled, and say to stop on the last three and to use exponential backoff. They also say not to resubmit the original paid request because a local process timed out.
A resend with the same Idempotency-Key is a replay of the original job, so a deliberate rerun after failed needs a new key.
import asyncio, os, httpx
H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
async def main(job_id: str):
async with httpx.AsyncClient(headers=H, timeout=60) as c:
while True:
r = await c.get(f"https://api.sume.com/v1/jobs/{job_id}/status")
d = r.json()["data"]
print(d["sume_status"])
if d["terminal"]:
return d["sume_status"]
await asyncio.sleep(d.get("next_poll_after_seconds") or 30)
print(asyncio.run(main(os.environ["JOB_ID"])))Which Seedance ids does Sume have?
The OpenAPI model enum lists seedance-2.5, seedance-2, seedance-2-fast and seedance-2-mini. Sume's Video Router notes say seedance-2 and seedance-2-mini are no longer picked by any default or routing preset but stay routable when requested explicitly. Read GET /v1/video-router/models for current limits before you pin one.
Sources
Related posts
More in Use cases
- Check 200 holiday clips before upload with a free probe-only inspect
A video-inspect call with frames false is a probe with no stills and no charge. Use it as a pre-upload audio gate, then pull stills only for clips you doubt.
- 300 holiday UGC clips on one plan: pace around queue_full 429s
A Pro workspace holds 4 processing and 20 queued jobs. Submit 300 avatar clips, treat queued as normal, and retry queue_full with the same idempotency key.
- Hour-long podcast video to clips: the 1800-second source cap
Sume's trim, detach and inspect tools read sources up to 1800 seconds, so a 60-minute episode must be split before import. Limits and a safe split plan.
- How many clips for a 10-minute faceless video? Timeline slot math
A 10-minute faceless video fits Timeline 1.0 comfortably: up to 200 slots, a render near $1.00, and limits on fades and single-pass renders to plan around.
Written by Sume