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 instances10,000100,000
Retention limit for completed Workflow 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 on a waiting state - either sleeping, waiting for a retry, or waiting for an event - do not count towards concurrency limits. This means that other queued instances will be scheduled when an instance goes from a running state to a waiting one, usually the oldest instance queued, on a best-effort basis. This state transition - running to waiting - may not occur if the wait duration is too 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 state and logs will be retained for 3 days on the Workers Free plan and for 7 days on the Workers Paid plan. ↩

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