Workflows keeps state 7 days now: store your Sume job ids

Cloudflare Workflows on Workers Paid now keeps finished instance state 7 days by default. Save the Sume job id and result URL in your own store.

4 min readSume
All posts

If a Cloudflare Workflow submits a Sume job, copy the job_id and the final media.sume.com URL into a store you control, because instance state is no longer a long-term record. Cloudflare's changelog says Workflows created on or after September 10, 2026 on Workers Paid keep completed and errored instance state for seven days by default, down from 30.

Sume behavior is from the Jobs and results docs; the Cloudflare entry was read 2026-09-30.

What did Cloudflare change?

The entry reads: “Workflows created on or after September 10, 2026, on the Workers Paid plan retain completed and errored instance state for seven days by default (previously 30 days).” The same page keeps the maximum retention at 30 days and the Free plan default at three days.

Retention as listed by Cloudflare, read 2026-09-30; job handles from the Sume Jobs and results docs.
ItemValueSource
Paid default, workflows created on or after Sep 107 daysCloudflare
Paid default before30 daysCloudflare
Maximum retention30 daysCloudflare
Free default3 daysCloudflare
What Sume tells you to storeThe job id from submitSume docs

What should I keep from a Sume job?

The Sume docs say to store the job id from the submit response so an integration can recover work after a process restart. Also keep status_url and result_url when present, and once the job completes, the artifact URLs from the result. Use Sume media URLs from the result; raw provider URLs are not public outputs.

Can I still look a job up after the instance is gone?

With the job id, yes: GET /v1/jobs/{job_id} returns the job record and GET /v1/jobs/{job_id}/result returns the result once it is completed. That is why the id, not the Workflow instance, is the handle worth saving. The docs do not state how long Sume keeps a finished job readable, so copy the media you need to your own storage.

curl https://api.sume.com/v1/jobs/job_123 \
  -H "Authorization: Bearer $SUME_API_KEY"

curl https://api.sume.com/v1/jobs/job_123/result \
  -H "Authorization: Bearer $SUME_API_KEY"

What happens if a step retries and submits twice?

Give every submit an Idempotency-Key derived from your own record, not from a random value per attempt. Reusing the same key for the exact same request returns the original job instead of billing a second one; reusing it for a different operation or payload is a 409 idempotency_conflict.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume