Cloudflare Workers Builds has increased the default retention period for completed builds and their logs to a fixed 90‑day period. Engineers who rely on build‑time diagnostics now have a longer horizon to retrieve information without having to implement external archiving.
Retention change details
Each build record, together with the full console output, remains accessible for exactly ninety days after the build finishes. After that point the build entry and its logs are automatically purged. The underlying version objects and any deployments created by the build are not removed; they continue to appear in the Worker’s version history and remain eligible for roll‑back operations. In the UI, the history is reachable via the View build history button on the Worker’s Deployments tab.
Operational impact
Longer log availability simplifies post‑mortem analysis of intermittent failures, especially when the issue surfaces days after deployment. Teams should review their internal log‑retention policies to decide whether the 90‑day window satisfies compliance or audit requirements, or whether they need to export logs earlier. Because logs are deleted automatically, any process that expects indefinite access must be adjusted to fetch and store logs before the expiration deadline.
Build logs often contain environment variables or debug output; the extended window therefore lengthens the period during which potentially sensitive information resides in the platform. Practitioners should consider redacting or limiting such data in build scripts to reduce exposure risk.
Access methods
Build history can be inspected through the View build history button in the Worker’s Deployments tab. The same data is also exposed via the Workers Builds API, allowing scripted retrieval or integration with existing monitoring pipelines. For builds that must be retained beyond the automatic window, the API provides a Get build logs endpoint that returns the raw log payload, which can be saved to an external store.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Update any CI/CD or observability tooling to query the Builds API before the 90‑day cut‑off if you need permanent records. Incorporate the new retention period into incident‑response runbooks, and verify that version‑history roll‑backs remain unaffected by log deletion. Consider automating a nightly export to your own log archive to guarantee availability for compliance audits. Finally, consult the Workers Builds limits documentation for any quota considerations that may affect high‑frequency build pipelines.
