Skip to content
Cloudflare Docs

Limits

Limits that apply to authoring, deploying, and running Workflows are detailed below.

Many limits are inherited from those applied to Workers scripts and as documented in the Workers limits documentation.

FeatureWorkers FreeWorkers Paid
Workflow class definitions per script3MB max script size per Worker size limits10MB max script size per Worker size limits
Total scripts per account100500 (shared with Worker script limits
Compute time per step 110 ms30 seconds (default) / configurable to 5 minutes of active CPU time
Duration (wall clock) per step 1UnlimitedUnlimited - for example, waiting on network I/O calls or querying a database
Maximum persisted state per step1MiB (2^20 bytes)1MiB (2^20 bytes)
Maximum event payload size1MiB (2^20 bytes)1MiB (2^20 bytes)
Maximum state that can be persisted per Workflow instance100MB1GB
Maximum step.sleep duration365 days (1 year)365 days (1 year)
Maximum steps per Workflow 210241024
Maximum Workflow executions100,000 per day shared with Workers daily limitUnlimited
Concurrent Workflow instances (executions) per account 32510,000
Maximum Workflow instance creation rate 4100 per second 5100 per second 5
Maximum number of queued instances100,0001,000,000
Retention limit for completed Workflow instance state3 days30 days 6
Maximum length of a Workflow name 764 characters64 characters
Maximum length of a Workflow instance ID 7100 characters100 characters
Maximum number of subrequests per Workflow instance50/request1000/request

waiting instances do not count towards instance concurrency limits

Instances that are in a waiting state — either sleeping via step.sleep, waiting for a retry, or waiting for an event via step.waitForEvent — do not count towards concurrency limits. This means you can have millions of Workflow instances sleeping or waiting for events simultaneously, as only actively running instances count toward the 10,000 concurrent instance limit. However, if there are 10,000 concurrent instances actively running, an instance that has been in a waiting state will be queued instead of resuming immediately. When an instance transitions from running to waiting, other queued instances will be scheduled (usually the oldest queued instance, on a best-effort basis). This state transition may not occur if the wait duration is very short.

For example, consider a Workflow that does some work, waits for 30 days, and then continues with more work:

src/index.ts
import {
  WorkflowEntrypoint,
  WorkflowStep,
  WorkflowEvent,
} from "cloudflare:workers";


type Env = {
  MY_WORKFLOW: Workflow;
};


export class MyWorkflow extends WorkflowEntrypoint<Env> {
  async run(event: WorkflowEvent<unknown>, step: WorkflowStep) {
    const apiResponse = await step.do("initial work", async () => {
      let resp = await fetch("https://api.cloudflare.com/client/v4/ips");
      return await resp.json<any>();
    });


    await step.sleep("wait 30 days", "30 days");


    await step.do(
      "make a call to write that could maybe, just might, fail",
      {
        retries: {
          limit: 5,
          delay: "5 second",
          backoff: "exponential",
        },
        timeout: "15 minutes",
      },
      async () => {
        if (Math.random() > 0.5) {
          throw new Error("API call to $STORAGE_SYSTEM failed");
        }
      },
    );
  }
}

While a given Workflow instance is waiting for 30 days, it will transition to the waiting state, allowing other queued instances to run if concurrency limits are reached.

Increasing Workflow CPU limits

Workflows are Worker scripts, and share the same per invocation CPU limits as any Workers do. Note that CPU time is active processing time: not time spent waiting on network requests, storage calls, or other general I/O, which don't count towards your CPU time or Workflows compute consumption.

By default, the maximum CPU time per Workflow invocation is set to 30 seconds, but can be increased for all invocations associated with a Workflow definition by setting limits.cpu_ms in your Wrangler configuration:

{
  // ...rest of your configuration...
  "limits": {
    "cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
  },
  // ...rest of your configuration...
}

To learn more about CPU time and limits, review the Workers documentation.

Footnotes

  1. A Workflow instance can run forever, as long as each step does not take more than the CPU time limit and the maximum number of steps per Workflow is not reached. ↩ ↩2

  2. step.sleep do not count towards the max. steps limit ↩

  3. Only instances with a running state count towards the concurrency limits. Instances in the waiting state are excluded from these limits. ↩

  4. Each instance created or restarted counts towards this limit ↩

  5. Workflows will return a HTTP 429 rate limited error if you exceed the rate of new Workflow instance creation. ↩ ↩2

  6. Workflow instance state and logs will be retained for 3 days on the Workers Free plan and for 30 days on the Workers Paid plan. ↩

  7. Match pattern: _^[a-zA-Z0-9_][a-zA-Z0-9-_]\*$_ ↩ ↩2