Cloud Parts

Cloudflare Workflows

Durable execution on Cloudflare Workers: a workflow is ordinary TypeScript or Python code split into steps, and each step’s result is saved so a failed run retries that step and carries on instead of starting over.

What it is
Workflow orchestration
Type
Commercial product
Made by
Cloudflare, Inc.
License
Proprietary
Facts checked
12 October 2026
Website

What it is

A workflow is a class that extends WorkflowEntrypoint with a run(event, step) method. Inside it, step.do(name, callback) runs a piece of work and saves whatever it returns (up to 1 MiB, or more as a stream); step.sleep and step.sleepUntil pause for up to a year; step.waitForEvent blocks until something outside sends a matching event, through the binding’s sendEvent() or the REST API, or a timeout (24 hours by default) passes. If a step throws, only that step is retried: by default 5 more times with an exponential delay starting at 10 seconds and a 10-minute timeout per attempt, all configurable, and a NonRetryableError stops it at once. When the instance resumes, completed steps return their saved results instead of running again, so step names act as cache keys and must be deterministic.

Each instance runs next to its own engine, a SQLite-backed Durable Object that executes the steps and stores their results, so instances are isolated from each other and nothing needs a separate database. You start instances from a Worker binding with create() or createBatch(), from the REST API or Wrangler, or on a cron schedule. Steps are billed like Workers for requests and CPU time, which is not charged while waiting; since August 10, 2026 the Paid plan also counts steps (500,000 a month included, then $0.80 per 100,000) and stored state (1 GB-month included, then $0.20 per GB-month).

Why teams pick it

  • Workflows are plain code, not a DSL: steps can be created in loops and branches, and every step can have its own retry limit, delay, backoff and timeout
  • Waiting is cheap: sleeping or waiting instances use no CPU time and don’t count toward the concurrency limit, so millions can sit waiting for events at once
  • No cluster or database to run: each instance’s state lives in its own Durable Object, and instances scale with Workers
  • Long pauses are built in: step.sleep for up to 365 days and waitForEvent for webhooks or human approval

Watch out for

  • Each step’s result is capped at 1 MiB unless returned as a stream, and an instance can store at most 1 GB of state on Paid (100 MB on Free)
  • Steps run with Workers CPU limits: 30 seconds by default and 5 minutes at most on Paid, 10 ms on Free
  • 10,000 steps per workflow by default (25,000 at most), so very long loops have to be split across several instances
  • Code outside step.do reruns on every resume, so side effects, randomness and step names must be handled carefully; completed state is kept only 30 days on Paid (3 on Free)

Alternatives

What all workflow orchestration have in common →
AWS Step FunctionsAWSAWS’s serverless workflow engine: state machines in JSON that call AWS services directly.PrefectOpen sourceA Python workflow orchestrator where a pipeline is an ordinary function decorated with `@flow`, with retries, caching, schedules and a UI added around it.TemporalOpen sourceAn open-source durable execution engine: you write workflows as ordinary code and they survive crashes.

How it fits with other technologies

Charge, wait for approval, then ship; each step is retried on its own · ts

import { WorkflowEntrypoint, WorkflowEvent, WorkflowStep } from "cloudflare:workers";

type Params = { orderId: string };

export class OrderWorkflow extends WorkflowEntrypoint<Env, Params> {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const charge = await step.do(
      "charge card",
      { retries: { limit: 10, delay: "10 seconds", backoff: "exponential" }, timeout: "5 minutes" },
      async () => chargeCard(event.payload.orderId), // result is saved
    );

    await step.waitForEvent("wait for approval", { type: "approved", timeout: "7 days" });
    await step.sleep("cool-off period", "1 hour");

    await step.do("ship order", async () => shipOrder(event.payload.orderId, charge.id));
  }
}

// From a Worker: const instance = await env.ORDERS.create({ id: orderId, params: { orderId } });
// Later:        await instance.sendEvent({ type: "approved", payload: { by: "ops" } });

See it in a real stack

No architecture uses Cloudflare Workflows yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2024–2026

As more developers built on Workers, R2 and Workers AI, Cloudflare saw them writing multi-step programs: process an upload, call an AI model, call a third-party API, update a database. Any of those calls can fail, and making the whole sequence survive failures meant writing retry, backoff and state-saving code by hand. Cloudflare announced Workflows, its take on “durable execution”, during Developer Week in 2024, and opened a public beta for Free and Paid plans on October 23, 2024, in a post by Sid Chatterjee, Matt Silverlock and Celso Martinho.

Cloudflare built Workflows entirely on its own platform. Stateless Workers serve the configuration API and the binding; one SQLite-backed Durable Object per account, the account controller, stores the account’s workflows, versions and instances; and every instance gets its own engine, another SQLite-backed Durable Object that runs the steps through JavaScript RPC and records their results. What set it apart from other durable execution systems, Cloudflare argued, is that it also runs the compute and storage, so there is no cluster to scale up on Monday morning and down at night.

Workflows became generally available on April 7, 2025, together with the waitForEvent API for webhooks and human approval. Python workflows entered open beta in August 2025, and in July 2026 Cloudflare added per-step billing, with step and storage charges starting no earlier than August 10, 2026.

Why it’s built this way

Plain code instead of a state machine or DSL
Early prototypes modeled the engine as a state machine, but that needs to understand the user’s code ahead of time, which means a costly build step. The team instead modeled the engine as a game loop that keeps running the user’s code until the last step completes, so steps can be created dynamically, conditionally and in loops.
One Durable Object per instance
Every engine is a SQLite-backed Durable Object, so each instance’s runtime and state are isolated, and scaling to huge numbers of instances becomes a problem Durable Objects already solve.
Steps as the unit of retry and caching
Saving each step’s result means a failure later on doesn’t repeat earlier work, such as calling an expensive third-party API again or getting rate limited by it.

Timeline

  1. 2024

    Announced during Developer Week

  2. 2024

    Public beta on October 23, open to Free and Paid plans

  3. 2025

    Generally available on April 7, with waitForEvent

  4. 2025

    Python Workflows enters open beta in August

  5. 2026

    Steps can return streamed output in March

  6. 2026

    Per-step and storage billing from August 10

Sources8 · facts checked 12 October 2026

Improve this page on GitHub