Cloudflare 524 on a Sume jobs_wait: transport, not job outcome

A 524 (or 522 / 523 / 525) on a Sume jobs_wait call is a transport failure, never a job outcome. The job is still running and still billing, so re-issue jobs_wait on the same ids or read jobs_status once. Do not resubmit the paid create.

Cloudflare's side is from its Error 524 page and Sume's from Jobs and results, both read 2026-10-01.

What does Cloudflare say a 524 is?

Cloudflare documents Error 524 as: it connected to the origin, but the origin did not provide an HTTP response before the default 125 seconds Proxy Read Timeout. Among its suggestions is to implement status polling of large HTTP processes to avoid hitting the error.

Nothing in that description says the work failed. It says the response did not arrive in time.

Why does jobs_wait have a bounded slice?

On remote MCP, timeout_seconds defaults to 50 and is capped at 55. The docs explain that a wait is one HTTP request held open with nothing transferring, and every edge eventually closes such a request. A larger value is clamped rather than rejected, and the response reports it in wait_slice_clamped. When a slice ends, the answer is wait_slice_expired, and you retry with the same ids.

What do I do when I see a 524?

How long a render can I wait for?

The docs say to wait for a ten-minute render by repeating the wait, not by asking for a longer one. Each call holds at most 55 seconds. For fan-outs, one batch jobs_wait with job_ids beats N single waits; see MCP jobs_wait for long video jobs.

Which Sume tools are safe to repeat?

Job reads (jobs_list, jobs_get, jobs_status, jobs_result, jobs_events, jobs_wait) are read tools, listed in MCP tools and gates. Repeating them does not create a second job. The create is the call that needs a stable idempotency_key, and the same key is reused only for the same operation and payload.