English for Cloudflare Workflows

Cloudflare Workflows lets you write multi-step, long-running processes as ordinary code while the platform durably tracks progress and automatically retries failures, so the vocabulary is largely about explaining durability guarantees clearly to teammates used to plain, stateless request handlers.

Key Vocabulary

Durable execution — a model where the state and progress of a multi-step process is persisted automatically, so if the process is interrupted partway through, it can resume from where it left off instead of restarting entirely. “If the worker crashes halfway through this ten-step process, we don’t restart from step one — durable execution means it resumes exactly where it stopped.”

Step — a discrete, named unit of work within a workflow, whose result is durably recorded once it completes successfully, so it never needs to be re-executed on retry. “This step already succeeded and its result is recorded — a retry after a later failure re-runs the failed step, not this one, since its output is already durably saved.”

Retry policy — the configuration governing how many times, and with what backoff strategy, a failed step is automatically retried before the workflow gives up and surfaces the failure. “We don’t need custom retry logic scattered through this code — the retry policy on this step already handles exponential backoff and a maximum attempt count.”

Sleep / delay — a workflow-native way to pause execution for a specified duration (even days) without holding compute resources the entire time, letting a workflow wait efficiently for a future point in time. “This isn’t a blocking timer holding a process open for three days — the workflow uses a native sleep, so it releases resources and simply resumes automatically when the delay ends.”

Idempotent step — a step written so that re-running it produces the same effect as running it once, which matters because durable execution guarantees at-least-once, not exactly-once, execution for any given step. “This step needs to be idempotent, since durable execution can re-run a step that partially completed — writing it so a repeat run doesn’t double-charge the customer is essential.”

Common Phrases

• “If this fails partway through, does it restart from scratch, or does durable execution let it resume from the last completed step?”
• “Is this step’s result already durably recorded, or could a retry re-run it unnecessarily?”
• “What’s the retry policy on this step — how many attempts, and what’s the backoff?”
• “Is this step actually idempotent, or could a retry cause a duplicate side effect?”

Example Sentences

Explaining the model to a new engineer: “We’re not managing our own state machine and database table to track progress here — Cloudflare Workflows durably tracks each step’s completion for us automatically.”

Discussing a design for a long wait: “Instead of a cron job polling every hour for three days, we can use a native sleep step, which resumes the workflow automatically without holding any compute the whole time.”

Reviewing a step for correctness: “This step charges a payment provider — we need to make sure it’s idempotent, since a retry after a transient failure could otherwise charge the customer twice.”

Professional Tips

• Lead with durable execution when explaining Workflows to engineers used to stateless request handlers — it reframes the entire mental model around resumability rather than statelessness.
• Be explicit in design discussions about which step boundaries make sense — grouping too much into one step reduces the granularity of what gets safely skipped on retry.
• Document the retry policy per step rather than relying on a single global default — some steps (like external payment calls) need much more conservative retry behavior than others.
• Flag any step with an external side effect and confirm it’s idempotent before merging — this is the single most common correctness gap in durable workflow code.

Practice Exercise

1. Explain to a teammate how durable execution differs from a stateless request handler that restarts entirely on failure.
2. Describe why a native sleep step is more efficient than a polling cron job for a multi-day wait.
3. Write a sentence flagging a payment-related step that needs to be made idempotent before merging.