Cloudflare’s published step and storage billing schedule for Workflows took effect on 10 August 2026. Workflows remains available on Workers Free and Paid and has been Generally Available since April 2025, but the cost model is no longer only requests and CPU. A useful estimate now has four dimensions: invocations, CPU time, executed steps, and persisted state over time.
That does not make every Workflow expensive. Free has clear allowances without overage charges, and Paid includes monthly usage before overage. The expensive mistake is designing a long path without measurement, retaining large completed state, and discovering the model only after events or failures multiply in production.
Official Workflows pricing and the step and storage billing announcement
Separate the four billing dimensions
1. Requests or invocations
Creating a Workflow instance is an invocation. Workflows on Workers Free share the 100,000-request daily allowance. Workers Paid includes 10 million requests per month, followed by $0.30 per additional million. Subrequests made by a Workflow do not add separate request charges in this dimension, although platform limits still apply.
2. CPU time
Workflows uses Workers Standard CPU pricing. Paid includes 30 million CPU milliseconds per month, followed by $0.02 per additional million. Free permits 10 ms of CPU per invocation. Time waiting for an API, paused by step.sleep, or otherwise idle does not consume CPU time. A flow can therefore span days of wall-clock time while using little active compute.
3. Steps
Free includes 3,000 steps per day. Paid includes 500,000 per month and charges $0.80 per additional 100,000. A small step still counts, so 20 steps per customer event become two million steps at 100,000 events. The pricing page says rollback handlers and retries are excluded from billable step count, but they still deserve monitoring because they can increase CPU, latency, and operational failure.
4. Storage
Free includes 1 GB. Paid includes 1 GB-month and charges $0.20 per additional GB-month. Storage covers running, errored, sleeping, and completed instances. Default state retention is three days on Free and 30 days on Paid. A large successful result retained for a month can cost more than its execution.
Model cost before implementation
Put four formulas in a spreadsheet or dashboard:
monthly_invocations = business_events × retry_or_replay_factor
monthly_steps = monthly_invocations × average_steps
step_overage = max(0, monthly_steps - 500000) / 100000 × $0.80
storage_overage = max(0, average_GB_month - 1) × $0.20
Then add request and CPU overage. Avoid using only the theoretical maximum. Measure average and P95 from test data, then add a burst case, an external-provider outage, and manual replay.
For example, an onboarding service with 80,000 monthly instances and nine average steps produces 720,000 steps. That is 220,000 above the Paid inclusion, or roughly $1.76 in step overage at the published unit rate before requests, CPU, and storage. It is not a final bill, but it shows that moving from nine to 14 steps matters more than micro-optimizing a few lines inside one step.
External service cost must also be included. LLM, email, payment, and storage calls can exceed the orchestrator cost. Calculate the whole accepted outcome: Cloudflare, provider charges, retries, support, and compensation after failure.
Distinguish useful boundaries from step noise
A valuable step marks a boundary that needs independent durability, retry, or evidence. Reserving inventory, creating a payment intent, writing an order, sending a receipt, or waiting for human approval are good candidates. Splitting every in-memory mapping into its own step increases count and state without adding recovery value.
The opposite extreme is also risky. One giant step can replay several side effects and obscure the failure point. Ask: If this unit fails, do I want to retry it independently with its output preserved? If yes, a step is probably useful. If it is a pure transformation, keep it inside the surrounding step.
Use stable business names such as reserve_inventory and send_receipt, not step_3. Clear names make logs and GraphQL stepCount analysis useful when comparing cost and failure paths.
Storage is the quiet cost center
Workflows persists outputs and execution state so an instance can recover. That durability is the product’s value, but it makes payload design a cost and privacy decision. Return an R2 object key instead of a large binary when possible. Persist an identifier and version instead of copying an entire customer record into every stage.
The Workers API supports per-instance retention:
await env.ORDER_WORKFLOW.create({
id: orderId,
params: { orderId },
retention: {
successRetention: "1 day",
errorRetention: "7 days",
},
});
Use shorter successful retention when permanent evidence already exists in the system of record, and longer error retention when investigation needs it. Do not shorten retention before mapping audit, support, dispute, and regulatory requirements. Saving storage must not delete records the business is obliged to keep.
Limits that shape the architecture
Paid allows 10,000 steps per instance by default and can be configured up to 25,000. Free permits 1,024. Maximum persisted state is 100 MB on Free and 1 GB on Paid. A non-stream step result and the initial event payload are each limited to 1 MiB. Paid CPU defaults to 30 seconds per step and can be raised to five minutes, while wall time can remain unlimited during I/O waits.
The current limits page also says Workflows cannot be deployed in Workers for Platforms namespaces. A multi-tenant platform running customer code should review Dynamic Workflows and its constraints instead of assuming a standard binding transfers into that namespace.
These are ceilings, not design targets. A Workflow approaching 25,000 steps or 1 GB of state deserves an architecture review before a limit increase.
Implementation and monitoring checklist
- Name the business event that creates an instance and define its idempotency key.
- Map each step’s side effect, retry, timeout, and compensation.
- Estimate invocations, average and P95 steps, CPU, output size, and retention.
- Keep state to identifiers and compact results; put large objects in R2.
- Set
successRetentionanderrorRetentionfrom the operating policy. - Add budget alerts and separate test from production usage.
- Query
stepCount, success, and failure through GraphQL Analytics. - Fail an external API after its side effect and verify retry does not duplicate payment or email.
- Monitor cost per successful outcome, not only per invocation.
- Revisit the model after seven and 30 days of real traffic.
Risk, availability, and compatibility limits
- Workflows is GA and available on Workers Free and Paid. Cloudflare documents no separate country restriction, while Enterprise compliance and price terms remain contractual.
- Free does not charge step or storage overage, but it can reach limits. A state write fails when the storage limit is exhausted.
- Published prices are in US dollars. Tax, currency conversion, and Enterprise terms can differ.
- Rates and allowances can change. Date every cost model and recheck before promising a fixed client price.
- Idle time does not consume CPU, but the instance can continue retaining billable state.
- Durable execution does not make a payment API, CRM, or email provider idempotent. External writes still need a business idempotency key.
Practical recommendation
Do not avoid Workflows only because steps now have a price, and do not use it for every background task because orchestration is convenient. It fits work that needs durable progress, independent retries, long waits, or an explainable path. A short stateless task may be simpler in a Queue consumer or normal Worker.
When pricing a business system, show the assumptions: event volume, average steps, retention, state size, and external providers. Include uncertainty, then reprice from observed data. Good design is not the fewest steps at any cost. It is the smallest set that preserves recovery and auditability without redundant state or repeated side effects.
Sources and review date
- Current Workflows pricing and billing dimensions
- Step and storage billing changelog
- Workers Free and Paid limits
- Instance retention options
- Generally Available announcement
- Product status, pricing, limits, and availability were reviewed on 29 August 2026.