Not if you review less often than the platform keeps it. Cloudflare Workflows created on Workers Paid from 10 September 2026 keep completed and errored instance state for seven days by default, down from 30. Set the investigation window with the business owner.
- 01Existing Workflows keep their settings. The paid maximum stays 30 days; Workers Free keeps its three-day default and limit.
- 02Workflow instance state and the business record are different things; expiry is not proof that records were lost.
- 03Longer storage is not automatically the answer. Faster alerts or a shorter review cycle may solve the problem.
In plain words
- API
- A way for one piece of software to ask another for information or send it an instruction.
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.
Who gets the new seven-day default
| Aspect | New paid Workflows | Existing paid Workflows | Workers Free |
|---|---|---|---|
| Which Workflows | Created on or after 10 September 2026 | Created before that date | Not covered in this note |
| Default | Seven days, down from 30 | Keep their current settings | Three days |
| Maximum | 30 days | 30 days | Three days |
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.
An error that waits for the fortnightly meeting
- 01
Automated task
Reports an error on a delivery exception.
- 02
Operations team
Reviews exceptions every second Monday, so nobody looks until the next meeting.
- 03
Workflow history
A seven-day window may be shorter than that review cycle.
- 04
Operations team
The order record still exists. The question is whether they can reconstruct what happened.
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.
Who decides what is kept, and for how long
Business owner
- Sets the longest realistic delay before investigation
- Includes weekends, absence and external support response time
- Names the evidence needed
Diagnostic evidence
- Record references and timestamps
- Final status and the failing stage
- Not complete customer messages or credentials by default
Workflow settings
- successRetention and errorRetention controls
- Configured through the API or dashboard
Separate review
- Access and retention review before storing any additional data
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.
Five checks on non-production records
- 01Run a successful case and a controlled failurePass when: The evidence available for each is recorded
- 02Follow the failure alertPass when: It reaches a named owner, not only a dashboard
- 03Compare retention with the real investigation delayPass when: The difference is written down
- 04Investigate after instance state expiresPass when: Approved business records and existing diagnostic systems are enough
- 05Repeat a request before retrying a failurePass when: Recovery creates no 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.
Sources & context
Sources checked 2026-09-15. Recommendations and illustrative scenarios are Noesis’s analysis, not claims of client results.