Will the failure details still be there when you investigate?

What changed—and who is affected.

Cloudflare published this change on 10 September 2026, effective for Workflows created on or after that date on Workers Paid. Completed and errored instance state is retained for seven days by default, down from 30. Existing Workflows keep their retention settings. The paid maximum remains 30 days; Workers Free keeps its three-day default and limit. We accessed the announcement on 15 September 2026. This is a specific platform change, not evidence that every automation tool now keeps less history. See source 1.

The business question.

Noesis analysis: will the evidence needed to investigate an exception still exist when someone notices it? This matters to businesses running connected order, fulfilment or reporting processes on the affected service. A task can finish technically while its business result remains unresolved. The team responsible for the outcome should therefore help decide the investigation window. A default chosen by the platform is not a substitute for that decision.

A hypothetical operations example.

Imagine a distributor that checks delivery exceptions every second Monday. An automated task reports an error, but nobody reviews it until the next meeting. Noesis analysis: a seven-day history window may be shorter than that review cycle. The point is not that an order record has been deleted: workflow instance state and the business record are different things. The risk to test is whether the team can reconstruct what happened. This is an invented example, not a Noesis client incident.

Choose the window before changing the setting.

Noesis recommendation: list one affected workflow, its business owner, its alert destination and the longest realistic delay before investigation. Include weekends, absence and external support response time. Then record which evidence the owner needs: record references, timestamps, final status and the failing stage. Avoid treating complete customer messages or credentials as useful diagnostic data by default. Any decision to store additional data needs a separate access and retention review; this note does not prescribe a legal retention period.

Run a bounded check.

Noesis recommendation: use non-production records and agree the expected evidence before the test. Do not alter live workflow settings solely because of this article.

• Create a successful case and a controlled failure. Check what evidence is available for each.
• Confirm that the failure reaches a named owner, not only a dashboard somebody might open.
• Compare the configured retention period with the actual investigation delay. Record the difference.
• Check how the team would investigate after instance state expires, using approved business records and existing diagnostic systems.
• Test a repeated request before retrying a failed operation. A recovery attempt must not create a duplicate business action.

Limits and release decision.

Cloudflare documents separate successRetention and errorRetention controls, with configuration available through the API and dashboard. See source 1. Noesis analysis: keeping errors longer may be useful, but longer storage is not automatically the right answer. Faster alerts or a shorter review cycle may address the problem. This note is based on documentation, not hands-on testing. It does not establish your current configuration, predict costs or prove that any records have been lost.

Make reliability part of the systems roadmap.

Noesis recommendation: bring one recurring exception and its current investigation process to a systems review. A useful first scope is an evidence map, an accountable owner and a tested recovery procedure. Measure time to notice, time to resolve and cases that cannot be explained. The aim is fewer unresolved exceptions—not a larger store of logs. Establish a baseline before claiming improvement.