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.

4 min readSume
All posts

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.

Higgsfield changelog entry for Sep 30, 2026 against Sume job statuses from Jobs and results, read 2026-10-02.
SymptomOn a Sume jobWhat to do
Generation took longersume_status queued or processing, terminal falseKeep polling; do not resubmit
Generation failedsume_status failed, terminal true, a public error on the jobRead the error, then submit again
Client timed out locallyThe job keeps running and still billsResume 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

All Use cases posts

Written by Sume