Cloudflare Workflows: Budget for Shorter Run History

The default changed, not the ceiling

A Cloudflare Workflow is a durable job made of steps. The platform persists enough state to resume the job after a wait or retry, then keeps the finished instance for a retention period after it completes or errors.

That retained instance is operational evidence. Cloudflare's instance API can return its status, parameters, output, step details, attempts, timing, and errors. If an old payment reconciliation, client import, or publishing job failed, this is the record that helps you reconstruct what happened.

The September change has three boundaries:

• A Workers Paid Workflow created on or after September 10 defaults to seven days for completed and errored instance state.
• An existing Workflow keeps its current retention behavior. Cloudflare did not shorten old Workflows retroactively.
• Workers Free stays at three days, which is both its default and its limit.

Paid still lets you retain state for up to 30 days. So Cloudflare lowered the default, not the maximum.

That distinction resolves an awkward documentation conflict. The pricing page was last updated July 21 and still calls 30 days the Paid default. The Workers API reference was updated August 12 and says an omitted retention setting uses the account maximum. Both pages predate the September 10 changelog.

Use the newer, narrower rule: seven days is the default for newly created Paid Workflows. Existing Paid Workflows are unchanged, and 30 days remains the Paid ceiling.

Seven days is now an incident deadline

The real question is not whether seven days sounds short. It is whether your team discovers important failures before the seventh day.

A backend lead running payment or order jobs may hear about a mismatch only when support or finance reconciles the record. If that happens after the retained instance expires, the team can still have an external transaction record while losing the Workflow's step attempts, error details, and outputs that explain the execution path.

An SRE has a second trap. Cloudflare keeps Workflow metrics queryable for 31 days, but that analytics window is not the same thing as detailed instance-state retention. A metric can show that a failure event occurred. It should not be treated as proof that the old instance's parameters, outputs, attempts, and errors are still available.

This is the same operating rule that applies to AI agent failure-analysis tools: evidence retention should match the delay between the failure and the moment somebody knows it matters.

For an agency technical lead, the danger is inconsistency. A long-running client Workflow created before the change may keep its old window, while a replacement created after the change silently gets seven days. The client runbook can be wrong even though the code path looks unchanged.

Split cheap success history from valuable error history

Cloudflare gives you two controls for a reason:

• successRetention is how long state stays after a successful completion.
• errorRetention is how long state stays after an errored or terminated end.

Successful runs often leave their durable business result somewhere else: an order row, an object key, a sent-message ID, or a completed import record. When that outside system is the source of truth, a short success window can be enough for immediate support and replay checks.

Errored runs are different. Their value is often the unfinished path itself. The failed step, prior attempts, input parameters, and intermediate output may be what the investigator needs. If failures can surface late, a longer error window is easier to defend than keeping every successful run for the same period.

The official change example makes that split directly:

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

That is an example, not a universal recommendation. Choose the error window from your longest realistic discovery and investigation delay. Choose the success window from how long operators need the Workflow record after the real result has landed in its system of record.

The storage math only works if you separate active state

Cloudflare prices Workflow storage in GB-months. On Workers Paid, the first 1 GB-month is included and additional storage costs $0.20 per GB-month. Cloudflare calculates the measure by averaging peak storage per day over a 30-day billing period.

The storage total spans running, sleeping, errored, and completed instances. That means shorter terminal retention can reduce finished-state storage, but it does not erase the state of jobs that are still active or sleeping.

The current pricing page says Workflows step and storage billing applies starting August 10, 2026. The older July billing notice only promised that billing would start no earlier than that date. The current page settles the published start date, but it still does not prove what any specific account will show on its next invoice.

Here is an explicitly hypothetical model, not a Cloudflare benchmark and not a promised saving.

Assume successful runs add 1 GB of newly retained state per day at steady volume. Active, running, and sleeping instances contribute another 0.5 GB-month in either scenario. To isolate the success-retention lever, exclude errored-state storage from the comparison. If errorRetention stays at 30 days, measure that state and add the same error-history line to both sides.

The modeled difference is $4.60. That is the whole reason to label the inputs. A team with tiny step outputs may save almost nothing. A high-volume Workflow that persists large results can have a much bigger retained-success line. The new default changes the multiplier, but your state size and completion rate determine the bill.

The honest limits

Thirty days is still the Paid maximum. If a customer, regulator, or monthly reconciliation can surface a problem after that window, Workflows instance state cannot be your only archive. Export the minimum evidence you need to a system with its own retention and access policy.

Longer error retention also stores more error state. The right policy is not "errors forever." It is enough time to discover and reconstruct the incident, followed by a compact durable record such as the instance ID, workflow version, timestamps, status, redacted error, and the business object it affected.

Short success retention has a dependency too. The successful outcome must already live somewhere trustworthy. If the Workflow output is the only record that an action happened, deleting it sooner reduces both storage and evidence.

Finally, per-instance overrides can fragment the policy. An agency with several creation paths can set the dashboard default correctly and still have one caller request another window. Retention belongs in code review, the runbook, and the cost model, not only in a dashboard setting.

What to do now

Act this week if you created a Paid Workflow on or after September 10, if failures can reach an owner after seven days, or if completed state is a visible storage line. Set success and error retention separately.

Wait on optimization if the Workflow is still a low-volume pilot and its retained state sits inside the included 1 GB-month. You should still make the policy explicit, because the investigation window matters even when the storage overage is zero.

You are unaffected by the default change if the Workflow already existed before September 10. Workers Free is also unchanged at a three-day default and limit. Neither case removes the need for an external record when the business must investigate beyond the platform window.

On Monday, audit every new Workflow creation path. Set both successRetention and errorRetention explicitly, then trigger a safe failure and confirm the last day that its detailed state can still be inspected. Put that date in the runbook before the first real incident tests it for you.

Get the next practical platform change in the newsletter.