Skip to content

limits.mdx

Latest commit

 

History

History
188 lines (134 loc) · 13.4 KB

limits.mdx

File metadata and controls

188 lines (134 loc) · 13.4 KB
pcx_content_type concept
title Limits
description Limits for Cloudflare Workflows, including maximum steps, payload sizes, and instance concurrency.
sidebar
order
4
products
workflows

import { Render, WranglerConfig } from "~/components";

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.

:::note

Workflows cannot be deployed to Workers for Platforms namespaces, as Workflows do not support Workers for Platforms.

:::

Feature Workers Free Workers Paid
Workflow class definitions per script 3MB max script size per Worker size limits 10MB max script size per Worker size limits
Total scripts per account 100 500 (shared with Worker script limits
Compute time per step 1 10 ms 30 seconds (default) / configurable to 5 minutes of active CPU time
Duration (wall clock) per step 1 Unlimited Unlimited - for example, waiting on network I/O calls or querying a database
Maximum non-stream step result per step 2 1MiB (2^20 bytes) 1MiB (2^20 bytes)
Maximum event payload size 1MiB (2^20 bytes) 1MiB (2^20 bytes)
Maximum state that can be persisted per Workflow instance 3 100MB 1GB
Maximum step.sleep duration 365 days (1 year) 365 days (1 year)
Maximum steps per Workflow 4 1,024 10,000 (default) / configurable up to 25,000
Maximum Workflow executions 100,000 per day shared with Workers daily limit Unlimited
Concurrent Workflow instances (executions) per account 5 100 50,000
Maximum Workflow instance creation rate 6 100 per second 7 300 per second per account 7, 100 per second per workflow
Maximum number of queued instances 100,000 2,000,000
Retention limit for completed Workflow instance state 3 days 30 days 8
Maximum length of a Workflow name 9 64 characters 64 characters
Maximum length of a Workflow instance ID 9 100 characters 100 characters
Maximum number of subrequests per Workflow instance 50/request 10,000/request (default) / configurable up to 10 million
Maximum number of retries per step 10,000 10,000

In JavaScript Workflows, if you need to persist large binary output from a step, return a ReadableStream<Uint8Array>. Streamed outputs still count toward the per-instance storage limit, so store very large or long-lived artifacts in external storage such as R2 and return a reference when appropriate.

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:

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) {
		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 seconds",
					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.

Cron-triggered instances on Workers Paid

On Workers Paid, Workflow instances created by schedules can run for up to one hour per cron firing without consuming a Workflow concurrency slot.

After that budget is used, the instance yields and enters the normal concurrency queue. It resumes when a concurrency slot is available. The instance does not fail, time out, or terminate because it used this cron concurrency budget.

Increasing Workflow step limits

Each Workflow instance supports 10,000 steps by default, but this can be increased up to 25,000 steps in your Wrangler configuration. Refer to Workflow step limits for more information.

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.

If your Workflow exceeds its CPU time limit, it will throw the following error:

Error: Worker exceeded CPU time limit.

This will appear as exceededCpu in wrangler tail outcomes and as exceededResources in Workers metrics.

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.

Increasing Workflow subrequest limits

A subrequest is any request that a Workflow makes to either Internet resources using the Fetch API or requests to other Cloudflare services like R2, KV, or D1. Because Workflows are long-running and often make many calls to external services or Cloudflare APIs, they can exceed the default subrequest limit.

If your Workflow exceeds its subrequest limit, it will throw the following error:

Error: Too many subrequests.

This will appear as exceededResources in Workers metrics and as exception in wrangler tail outcomes.

By default, the maximum number of subrequests per Workflow instance is 10,000 on Workers Paid plans, but this can be increased up to 10 million by setting limits.subrequests in your Wrangler configuration:

{
	// ...rest of your configuration...
	"limits": {
		"subrequests": 10000000, // 10 million (maximum)
	},
	// ...rest of your configuration...
}

Workers on the free plan remain limited to 50 external subrequests and 1,000 subrequests to Cloudflare services per invocation.

To learn more about subrequest 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. Applies to non-stream step.do() return values. In JavaScript Workflows, ReadableStream<Uint8Array> is also a supported serializable return type for larger binary output. ↩

  3. This total includes persisted bytes from streamed step outputs returned from JavaScript step.do() calls. ↩

  4. step.sleep does not count towards the maximum steps limit ↩

  5. Only instances with a running state count towards the concurrency limits. Instances in the waiting state are excluded from these limits. Workers Paid cron-triggered Workflow instances have a separate one-hour cron concurrency budget per firing. ↩

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

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

  8. 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. ↩

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