Can a Cloudflare Worker wait for a Sume video? Use a webhook

No, a Cloudflare Worker cannot wait for a Sume video with ctx.waitUntil. That call extends execution for up to 30 seconds after the response is sent, while a long-form Sume Format run typically takes 15 to 30 minutes. Start the run, return, and receive a webhook later.

The mismatch is a factor of thirty or more, so a design that tries to hold the Worker open will fail, and it will do so intermittently.

The same reasoning applies to other short-lived platforms such as edge functions and serverless handlers with a time limit. Whatever the limit, a video that takes tens of minutes should never be inside a request.

What waitUntil does

Cloudflare's page, read 2026-10-10, says ctx.waitUntil lets work continue after a response is returned, for uses like analytics events and cache writes. For HTTP-triggered Workers it extends execution for up to 30 seconds after the response is sent or the client disconnects, and all waitUntil calls in the same request share that window. Promises still pending after it are canceled.

That is the right tool for firing a request and not waiting for the answer. It is the wrong tool for waiting on a long job.

The pattern that works

In the request handler, call POST /v1/formats/{handle}/{slug}/runs with a communication webhook and a spend cap, store the run id, and return a 202 of your own. The Sume create call itself answers quickly with a receipt. When the run ends, Sume sends a terminal webhook to your public HTTPS route.

The Run webhooks page gives the envelope: request_id equal to the run id, a status of OK or ERROR, and a payload that is the receipt, or null above 1 MiB. Verify x-sume-webhook-signature, check the five-minute window, and dedupe on request_id before you do anything else.

Sketch the flow as three small pieces: a create route that stores the run id and returns at once, a webhook route that verifies and saves, and a reader route that shows the user the current state. Each finishes in well under a second, so none of them cares how long the video takes.

Where the state goes

A Worker has no memory between requests, so keep the run index in a store you already use, such as a database or key-value namespace. Write the run id and your record id at create time. In the webhook route, look up the record by run id and write the media URL back.

Keep the webhook route fast. Delivery times out at 10 seconds per attempt, with up to 10 attempts, so save the event and queue the rest. For a slow copy job, use a queue consumer rather than waitUntil, which has only 30 seconds.

A common mistake is to key the state by user or session. Key it by run id, because the webhook knows only the run id, and add your own record id as a column.

Backups

Webhooks can fail, so add a scheduled Worker that looks for runs still not terminal after your own deadline and reads their status_url. Cancel the ones that pass it. If a payload arrives as null with payload_too_large, fetch the result_url.