制限

Workflows の作成、デプロイ、実行に適用される制限は次のとおりです。

多くの制限は Workers スクリプトに適用される制限を引き継いでおり、Workers の制限 のドキュメントに記載されています。

JavaScript Workflows で、ステップから大きなバイナリ出力を永続化したい場合は、ReadableStream<Uint8Array> を返します。ストリーム出力もインスタンスあたりのストレージ制限に含まれるため、非常に大きい成果物や長く残す成果物は R2 などの外部ストレージに保存し、適切なときは参照を返します。

waiting 状態のインスタンス（step.sleep でのスリープ、リトライ待ち、または step.waitForEvent でのイベント待ち）は、同時実行数の制限に含まれません。そのため、スリープ中またはイベント待ちの Workflow インスタンスを同時に数百万持てます。制限（同時インスタンス 10,000）に含まれるのは、アクティブに running しているインスタンスだけです。 ただし、すでに 10,000 のインスタンスが同時に実行中の場合、waiting 状態だったインスタンスはすぐには再開されず、キューに入ります。 インスタンスが running から waiting へ遷移すると、ほかの queued インスタンスがスケジュールされます（通常は最も古いキュー済みインスタンスが、ベストエフォートで選ばれます）。待ち時間が非常に短い場合、この状態遷移は起きないことがあります。

たとえば、作業をしたあと 30 日待ち、そのあとさらに作業を続ける Workflow を考えます。

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");
				}
			},
		);
	}
}

ある Workflow インスタンスが 30 日待っているあいだは waiting 状態になり、同時実行数の上限に達している場合は、ほかの queued インスタンスが実行できます。

Workers Paid では、schedules で作成された Workflow インスタンスは、cron の発火ごとに最大 1 時間、Workflow の同時実行スロットを消費せずに実行できます。

そのバジェットを使い切ると、インスタンスは譲って通常の同時実行キューに入ります。同時実行スロットが空いたときに再開します。この cron 同時実行バジェットを使ったことが原因で、インスタンスが失敗したり、タイムアウトしたり、終了したりすることはありません。

Workflow の schedules には、次の制限が適用されます。

各 Workflow インスタンスはデフォルトで 10,000 ステップまで対応しますが、Wrangler 設定で最大 25,000 ステップまで上げられます。詳細は Workflow のステップ数制限 を参照してください。

Workflows は Worker スクリプトであり、Workers と同じ 呼び出しあたりの CPU 制限 を共有します。CPU 時間はアクティブな処理時間です。ネットワークリクエスト、ストレージ呼び出し、そのほか一般的な I/O の待ち時間は、CPU 時間にも Workflows のコンピューティング消費にも含まれません。

Workflow が CPU 時間の上限を超えると、次のエラーがスローされます。

Error: Worker exceeded CPU time limit.

これは wrangler tail の結果では exceededCpu、Workers のメトリクス では exceededResources と表示されます。

デフォルトでは、Workflow 呼び出しあたりの最大 CPU 時間は 30 秒です。Workflow 定義に紐づくすべての呼び出しで上げるには、Wrangler 設定で limits.cpu_ms を設定します。

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

[limits]
cpu_ms = 300_000

CPU 時間と制限の詳細は、Workers のドキュメント を参照してください。

サブリクエストとは、Workflow が Fetch API でインターネット上のリソースへ送るリクエスト、または R2、KV、D1 などのほかの Cloudflare サービスへ送るリクエストです。Workflows は長時間実行され、外部サービスや Cloudflare API を何度も呼び出すことが多いため、デフォルトのサブリクエスト制限を超えることがあります。

Workflow がサブリクエスト制限を超えると、次のエラーがスローされます。

Error: Too many subrequests.

これは Workers のメトリクス では exceededResources、wrangler tail の結果では exception と表示されます。

デフォルトでは、Workflow インスタンスあたりのサブリクエスト最大数は Workers Paid プランで 10,000 です。Wrangler 設定で limits.subrequests を設定すると、最大 1,000 万まで上げられます。

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

[limits]
subrequests = 10_000_000

Free プランの Workers は、呼び出しあたり外部サブリクエスト 50、Cloudflare サービスへのサブリクエスト 1,000 のままです。

サブリクエスト制限の詳細は、Workers のドキュメント を参照してください。

ウォールタイム（ウォールクロック時間とも呼ばれます）は、呼び出しの開始から終了までの経過時間の合計です。ネットワークリクエスト、I/O、その他の非同期処理の待ち時間も含みます。CPU 時間 とは異なります。CPU 時間は、CPU がコードを実際に実行している時間だけを測ります。

次の表は、開発者プラットフォーム全体における Worker の呼び出し種別ごとのウォールタイム上限です。