Cloudflare Workers: Separate Response Success from Background Completion

A Cloudflare Worker should return a success message that matches the work already guaranteed. If a response says a document is saved, the save must satisfy the application's contract. If the response merely accepts a job, the interface should show that the result is still pending.

Cloudflare's context documentation explains that waitUntil can continue work after returning a response, within its execution limits. It also states that work needed for the response should be awaited. This distinction is more important than making every request appear fast.

Classify work by its consequence

Separate the primary user operation from supporting work. Saving the requested document is different from recording an aggregate usage event. A failed usage event may not invalidate the document save; a failed save certainly changes what the user should be told.

Write a short contract for each operation: what must exist before success, what may happen later and what requires a visible failure state. Use that contract to decide where work belongs.

Do not move an essential write after the response merely to improve the response-time graph.

Use a concrete text workflow

Contador de palabras, contador de caracteres describes a Spanish text-analysis utility and is declared in the Workers catalogue. The listing does not reveal its request implementation.

For a separate utility you are building, counting pasted text, saving a draft and generating a downloadable report could be three different operations. Counting might be immediate, saving needs a durable result, and a large report might become a tracked job.

Users should not have to understand the runtime to distinguish those outcomes.

Keep best-effort work visibly separate

A small supporting operation may fit work that continues after the response. Review the current runtime limits and the failure handling of the exact operation. An unawaited promise is not a reliable substitute for an explicit lifecycle decision.

Log enough context to diagnose failure without copying the user's full text into operational logs. A task reference and error category may be sufficient.

If losing the work would break the product promise, choose a design with the necessary durability and retries rather than hoping it finishes before execution ends.

Give durable jobs a status model

For queued work, expose states that answer useful questions: was the request accepted, is it running, has it completed and can it be retried? Keep repeated delivery tied to the original operation so retries do not create duplicate user results.

A completed job should point to its authoritative output. A failed job should explain whether input must be corrected, a dependency is unavailable or an operator is investigating.

Preserve the distinction between a failed attempt and an abandoned request. A retry can be healthy while the overall request remains pending.

Rehearse interrupted outcomes

In an environment you control, interrupt a supporting call, delay a dependency and repeat a submitted operation. Compare the returned message, stored state and eventual output.

The important observation is consistency between those three surfaces. A quick HTTP response with an absent result is not a successful workflow.

Review the binding and environment guide before running those tests so they operate on the intended resources. Together, the checks establish both where the work is permitted and when the product may honestly describe it as complete.