Every Step Now Has a Price Tag: What Cloudflare Workflows' Per-Step Billing Means for Your Orchestration Budget

On July 7, 2026, Cloudflare published a one-paragraph changelog entry that will change how much a durable workflow costs to run. Starting no earlier than August 10, 2026, Workflows — Cloudflare's durable-execution primitive for multi-step, retry-safe orchestration on Workers — will bill for step execution and storage usage on Paid plans. Request and CPU-time billing already applied since the public beta. Per-step metering is new, and it turns a primitive that read as "bundled" into one where every step.do(), step.sleep(), and step.waitForEvent() is a line item.

The Free plan keeps a bundled allowance. The Paid plan does not. If you run Workflows in production, next quarter's invoice will depend on how many steps your workflows actually take — including retries, branches, and the steps you added for resilience and never thought of as cost.

This post works the numbers: what the new billing dimensions actually meter, what three real pipelines cost before and after August 10, why this is the third time in seven months a Cloudflare primitive went from bundled to metered, and where a self-hosted orchestrator on owned Hetzner hardware stops being a philosophical choice and becomes the cheaper one.

What Per-Step Billing Actually Meters​

Cloudflare Workflows pricing has four dimensions after August 10. Two are old, two are new:

The docs define a step as "each unit of work executed by a Workflow, including step operations such as sleeping or waiting for events." That last clause matters. A step.sleep("wait-for-approval", "24h") that previously cost nothing beyond the single request that created it will cost a step. A step.waitForEvent("webhook-callback") that idles for hours will cost a step. The idle sleep itself still does not burn CPU, but the step that represents the wait is now metered.

Cloudflare's own pricing page lists storage at $0.20 per GB-month and frames CPU time in the same units as Workers ($0.02 per million CPU-milliseconds on the standard model). Per-step pricing had not been published as a precise per-step dollar figure at the time of the July 7 changelog — the page notes "step and storage billing to start no earlier than August 10, 2026" and that Free-plan bundled step/storage allowances will remain. The exact per-step rate will land in the August pricing update. What is already clear is the shape: total bill becomes a function of step count, not just wall-clock compute.

Two other numbers from the changelog are worth anchoring now. In March 2026, Cloudflare raised the per-workflow step limit from 1,024 to 25,000 steps per instance, with persisted state caps of 100 MB (Free) and 1 GB (Paid). The platform was explicitly inviting more complex, longer-running workflows in the same quarter it announced those workflows would be metered per step. That is not a contradiction — it is a pricing model catching up to a capability.

Three Pipelines, Before and After August 10​

The question is not what a step costs in isolation. It is what a whole pipeline costs when step count multiplies with retries, branches, and the orchestration patterns agents and deploy automation actually use. Three examples at different step densities show where the meter moves first.

Pipeline A: A deploy pipeline (low step count)​

A typical CI/CD deploy workflow: build, test, push image, deploy to staging, run smoke tests, promote to production. Six steps, no retries on the happy path, a couple of sleeps for propagation checks.

At this scale, the new billing dimension is noise. Even if per-step pricing lands at fractions of a cent per thousand steps, a deploy pipeline that runs a few hundred times a month is dominated by CPU time and request count, not step count. Cloudflare Workflows remains effectively free for this shape on any plan. This is the workload where Workflows still wins outright — you would not self-host Temporal to run six steps.

Pipeline B: An agent-orchestration loop (medium step count)​

An AI agent that researches, drafts, and verifies — the kind of loop that wraps an LLM call in durable steps so a timeout or rate limit does not lose progress. Each agent iteration is 4–6 steps (fetch context, call model, parse, verify, persist), and a single task fans out to 5–10 parallel sub-agents.

Now the meter is visible. At 450,000 steps a month, plus persisted state for each workflow's intermediate results, the step/storage dimensions stop being rounding error. The pipeline still fits comfortably inside Workflows' 25,000-steps-per-instance ceiling — you are not hitting limits, just paying per unit in a way you were not before. This is the shape where the question "should this run on Workflows or on a self-hosted orchestrator?" becomes a real cost comparison rather than a philosophical one.

Pipeline C: A retry-heavy data pipeline (high step count)​

A pricing or indexing pipeline that rebuilds across regions and phases — the Cloudflare-adjacent example from the wild is a weekly pricing rebuild that became a Workflows workflow with 27 regions × 9 phases ≈ 243 steps per run, plus retries for transient failures. Scale that to daily, add per-step retries at 3× for rate-limited API calls, and a single logical "run" becomes 700+ steps.

Pipeline C is where storage also starts to matter. A 243-step workflow persisting intermediate state across phases holds that state as GB-months. At a few megabytes per workflow × 30 concurrent workflows, storage billing is small in absolute dollars but — like step billing — was previously bundled at zero marginal cost. After August 10, it is not.

The through-line across all three: the new bill is proportional to orchestration complexity, not just compute. The more you lean into what Workflows is for — retries, sleeps, event waits, fan-out — the more the new dimensions capture what used to be free. A workflow that is simple and linear barely notices. A workflow that is durable in the interesting sense does.

The Bundled-to-Metered Pattern, Three Times in Seven Months​

Workflows' step billing is not an isolated change. It is the third time in seven months that a Cloudflare primitive moved from bundled to separately metered:

The docs even carry the breadcrumb trail: the Workflows changelog explicitly calls out that "requests and CPU time billing have been enabled since the initial public beta and is not changing" — drawing a clean line between the old dimensions and the new ones. The Durable Objects pricing page went through the same before/after, with a storage backend split (SQLite recommended, KV legacy) that only mattered once storage itself was metered.

None of these changes are unreasonable on their own. Durable state costs money to persist. Steps cost money to schedule. The issue is the cumulative shape: each new metered dimension makes a platform that markets as "no egress fees" and "flat" a little less flat, one primitive at a time. Cloudflare's zero-egress stance across Workers, R2, and CDN is still real — but the free part increasingly describes stateless compute, while the stateful, durable, agentic layer underneath any interesting app is metered on its own schedule.

For a team building agent pipelines — the exact workload Cloudflare's "Temporary Accounts for agents" feature is courting — the relevant comparison is not "Workflows vs not having durable execution." It is "Workflows at per-step metering vs owning the orchestrator."

What the Same Pipelines Cost on Owned Hardware​

A self-hosted orchestrator — Temporal on a Cluster API-managed Hetzner fleet is the canonical example — has a different cost shape entirely. You pay for the machine, not the step.

A minimal Temporal cluster (frontend, history, matching, worker) fits on a single Hetzner CX22 or CPX11 at €4–7 per month. A production setup with separate history persistence (PostgreSQL or Cassandra) and a worker pool might span two to three CX22-class nodes, on the order of €15–25 per month all-in on current Hetzner Cloud pricing. That number does not change when a workflow goes from 6 steps to 600 or from 300 runs a month to 30,000. CPU, memory, and disk are on the box whether you use them or not, and cross-region private networking between owned Hetzner locations is not a metered line item.

Where the comparison lands depends on pipeline shape:

• Pipeline A (deploy, ~2K steps/month): Cloudflare Workflows is cheaper. The self-hosted cluster's flat €15–25 exceeds the pennies of per-step billing at this volume. You are paying for operational overhead you do not need.
• Pipeline B (agent loop, ~450K steps/month): Roughly at parity or tipping toward self-hosted, depending on the exact per-step rate and storage. The flat machine cost starts to look like a ceiling against a variable bill that scales with task count.
• Pipeline C (data pipeline, ~60K–80K steps with retries): Self-hosted wins on predictability even when absolute dollars are close. The variable bill has retries as a cost multiplier. The flat bill does not — a retry is just more CPU on a machine you already paid for.

The honest caveat: self-hosting Temporal is not free in operational terms. You run the cluster, you handle upgrades, you own the failure modes. Cloudflare runs the control plane for you. The cost comparison above is infrastructure cost only — the operational cost of running Temporal has to be weighed against the operational cost of managing per-step billing complexity and the risk that the next changelog adds another dimension to the variable bill.

That risk is not hypothetical. It is the pattern the last seven months demonstrated. A flat Hetzner invoice is boring. That is its advantage.

A Decision Framework for Your Next Durable Workflow​

Use this to decide before August 10, not after:

1. Count your steps honestly. Include retries (multiply by your observed retry rate), sleeps, event waits, and fan-out branches. A workflow that reads as "10 steps" in code can be 40 in execution. If you do not have step-level analytics yet, Cloudflare's own Workflows analytics now exposes stepCount — query it for a week before committing to a cost model.

2. Check whether you are Cold or Hot. Sparse, bursty workflows (deploy pipelines, infrequent cron jobs) favor pay-per-step. Dense, always-on orchestration (agent loops, indexing pipelines, multi-tenant task queues) favors a flat-cost box where utilization, not invocations, drives economics.

3. Price the storage dimension, not just steps. Long-running workflows that hold state for hours or days accumulate GB-months. A workflow that sleeps for 24 hours waiting for human approval holds that state for 24 hours. Multiply state size × retention duration × workflow concurrency. The number is often larger than the step count suggests.

4. Compare to a single CX22, not to "self-hosting in general." The relevant self-hosted number is not "run your own data center." It is one to three Hetzner Cloud VMs under Cluster API, with Temporal or your preferred orchestrator, where the monthly bill is the same kind of number every time. If that number is lower than your projected Workflows bill at expected scale, own the orchestrator. If it is higher, rent the steps and revisit when scale changes.

5. Assume the next primitive will be metered too. If your architecture ties every durable capability to a separate pay-per-use service, each new metered dimension multiplies. An architecture that owns the orchestration layer and rents only the edges (CDN, object storage) has fewer dimensions that can change underneath it.

Closing​

Cloudflare Workflows going per-step is not a price hike in the usual sense. It is a pricing model becoming more granular — which is another way of saying less predictable for the workloads that use the platform hardest. For small, simple workflows, the change barely registers. For agent loops, data pipelines, and anything retry-heavy, the bill now scales with orchestration complexity itself, not just the compute underneath it.

That is a reasonable thing for a vendor to charge for. It is also exactly the kind of cost that a self-hosted PaaS was built to not have — because when the orchestrator runs on a box you own, the question "how many steps did that job take" was never a metered question to begin with.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. One flat Hetzner bill, no per-step meter. Star the repo on GitHub or deploy your first app today.