Cloudflare Workflows — the durable-execution engine Cloudflare built on top of Workers for orchestrating multi-step, long-running jobs — started charging per step on August 10, 2026. One developer who'd already migrated an ingestion platform onto it posted a rough estimate of what the change would do to their bill: from $0/month to somewhere around $1,600/month, across 30 workflows and roughly 20 million instances a month. Nobody enjoys that kind of email from their cloud bill.
Here's what actually changed, what it costs in practice, and how to figure out where you land before Cloudflare tells you.
What Workflows is, and what just changed
Workflows lets you write multi-step jobs — an order pipeline, a data ingestion run, anything that needs to survive a crash partway through — where each step (step.do(), step.sleep(), step.waitForEvent()) is independently retriable. If payment processing fails, only that step retries; the inventory check that already succeeded doesn't re-run. It's built for exactly the kind of orchestration that used to mean standing up a real queue and a state machine.
Until this August, Cloudflare billed Workflows the same way it bills Workers: active CPU time, not idle time spent waiting on an API or a database. That's still true. What's new is a second, separate meter: every step you execute now counts against a monthly allowance, and past that allowance, you pay per step.
The actual rate card
Per Cloudflare's pricing reference:
| Free plan | Paid plan | |
|---|---|---|
| Steps | 3,000/day included | 500,000/month included, then $0.80 per additional 100,000 |
| Storage | 1 GB-month included | 1 GB-month included, then $0.20/GB-month |
| Requests | 100,000/day (shared with Workers) | 10M/month included, then $0.30/million |
| CPU time | 10ms/invocation | 30M ms/month included, then $0.02/million ms |
A "step" is any unit of work the Workflow executes — including sleeps and event waits, not just code. Rollback handlers and retries don't count as extra steps, only the original execution does. Storage is billed as GB-month, averaged over peak daily storage across running, sleeping, errored, and completed instances — retained 3 days on Free, 30 on Paid by default.
Requests and CPU time are unchanged since the public beta. Steps and storage are the two new line items, and steps are the one that actually moves the needle for most workloads.
Running the numbers
Start small. A single order-fulfillment workflow — validate, charge, provision, confirm — at 100,000 orders/month is 400,000 steps/month. That's under the 500,000 included allowance. Cost: $0. Most small teams will never notice this change.
Now scale it up. The developer above didn't publish their exact steps-per-instance breakdown, but you can back into it: at ~20 million instances/month, their reported ~$1,600/month implies roughly 10 billable steps per instance. Here's that math laid out, so you can plug in your own numbers:
| Steps per instance | Total steps/month | Billable (over 500K) | Monthly cost |
|---|---|---|---|
| 2 | 40M | 39.5M | $316 |
| 4 | 80M | 79.5M | $636 |
| 6 | 120M | 119.5M | $956 |
| 8 | 160M | 159.5M | $1,276 |
| 10 | 200M | 199.5M | $1,596 |
The formula, if you want to run your own: (instances/month × steps/instance − 500,000) ÷ 100,000 × $0.80. Ten minutes with your own instance count and average step count per workflow gets you a real number instead of a surprise.
The part that actually stings
Here's the thing that makes this more than a routine price increase: Cloudflare's own documentation tells you to make your steps granular — split independent operations into separate steps so each one retries on its own instead of re-running the whole workflow on a transient failure. That's good architecture. It's also now the thing that multiplies your bill.
A workflow with two consolidated "mega-steps" costs a fraction of the same workflow split into ten granular, individually-retriable ones — even though the granular version is more resilient and more in line with what Cloudflare itself recommends. The developer in that community thread put it plainly: teams that ignored the granularity advice are now paying roughly a tenth of what teams that followed it are paying. That's an unusual way to reward best practice, and — this being the internet — the thread's since gone quiet with zero replies, staff or otherwise, which is its own small commentary on how the announcement landed.
Auditing your own bill before it lands
Four things worth actually doing this week if you run anything on Workflows:
-
Count your step operations per instance. Every
step.do(),step.sleep(), andstep.waitForEvent()call in a typical run. Loops and retried-but-succeeding operations count once; failed-then-retried ones don't add extra per Cloudflare's rules. - Multiply by monthly instance volume, compare against the 500,000/month included allowance, and run the formula above.
- Look at retention. Paid plans default to 30 days of stored instance state. If you don't need a month of history, cutting retention shrinks the storage line — smaller than the step line for most workloads, but not nothing at scale.
- Decide, deliberately, whether to consolidate. Merging operations into fewer steps saves money. It also means a mid-workflow failure re-runs more work on retry. That's a real tradeoff, not a free optimization — make it on purpose, not by accident.
When it's worth looking elsewhere
If your workload is genuinely step-heavy and the math above lands somewhere uncomfortable, it's worth pricing out dedicated job platforms rather than assuming Workflows is your only option. Trigger.dev bills on compute-seconds and per-run invocation ($0.000025/run) rather than per step, which can work out cheaper for workflows with many small steps but modest total compute. Inngest bills per execution instead — 50,000/month free, then plans starting at $99/month for 1M executions — which is a different enough shape that it's worth modeling against your own instance count before assuming it's cheaper or pricier.
Neither is a drop-in replacement. You'd be trading Workflows' tight Workers integration for a different execution model and different failure-handling guarantees. But if the per-step math above is ugly, it's a real comparison worth running, not just a hypothetical.
Bottom line
The billing change itself is straightforward and clearly documented; what catches people is that Cloudflare's own architectural advice — granular, independently-retriable steps — is exactly what runs the bill up. If you're already on Workflows, don't wait for the invoice to find out where you land: count your steps, run the formula, and decide on purpose whether granularity is worth paying for on your specific workload.
- Count steps per instance and multiply by monthly volume against the formula above before assuming anything about your bill
- Treat step consolidation as a real reliability-vs-cost tradeoff, not a free win
- Check your storage retention setting if you're storing large instance state
- If the math is bad, model your workload against Trigger.dev and Inngest before ruling out a switch
Researched and drafted with AI assistance, checked against primary sources.
Top comments (0)