Cloudflare Workers Workflows now let you create up to a hundred instances in a single createBatch() call. The API returns a list of successfully created instances and an error array that explains any failures, and the new signature is available locally through wrangler types starting with version 4.148.0.
What Changed
The createBatch() method has been extended to accept an options object. You can either supply a count field to generate a series of identical instances, each receiving an auto‑generated ID, or provide an instances array where each element defines its own id and params. The call caps at 100 instances per request. The response shape now includes two arrays: created (the IDs that succeeded) and errors (objects with index, id, code, and message describing why a particular entry was rejected).
Why It Matters
Batch creation collapses what used to be dozens of individual create() calls into a single network round‑trip, reducing latency and API‑rate‑limit pressure. For CI pipelines, test harnesses, or any automation that spins up many workflow runs, the new pattern simplifies code and improves reliability. The type information is now exposed locally, so developers get compile‑time validation without needing to query the live service.
Implementation Details
Two usage patterns are supported:
- Uniform batch: pass
{ count: N, params: { … } }to createNinstances that share the same parameters. Each instance receives a system‑generated identifier. - Custom batch: pass
{ instances: [{ id: "my‑id", params: { … } }, …] }to control identifiers and per‑instance payloads.
Both patterns are usable from JavaScript or TypeScript. Example snippets:
const result = await env.MY_WORKFLOW.createBatch({
count: 10,
params: { report: "daily" }
});
const { created, errors } = await env.MY_WORKFLOW.createBatch({
instances: [
{ id: "order-1", params: { orderId: 1 } },
{ id: "order-2", params: { orderId: 2 } }
]
});
for (const err of errors) {
console.log(err.index, err.id, err.code, err.message);
}
To access the new typings locally, ensure your development environment runs Wrangler 4.148.0 or later.
Operational and Security Considerations
Because a single request can now launch up to 100 workflow instances, monitoring should be adjusted to capture batch‑level metrics (e.g., total instances created per minute) rather than per‑instance counters. Alerting on the errors array is advisable; a sudden rise may indicate parameter validation failures or quota exhaustion.
From a security perspective, the batch payload still travels over the same authenticated channel as individual calls, so existing IAM policies remain applicable. However, the ability to specify arbitrary id values means callers must validate that supplied identifiers do not collide with protected naming schemes or expose internal identifiers. Any per‑instance params should continue to be sanitized according to the workflow’s own validation logic.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopt the new createBatch() signature wherever you currently loop over create() calls. Update your Wrangler version to unlock local type checking, and revise monitoring dashboards to aggregate batch results. Treat the errors array as a first‑class response element—log and act on it rather than assuming all instances succeeded. Finally, review any naming conventions for workflow IDs to ensure that externally supplied IDs cannot be abused.
