A Worker rollback creates an active deployment using a previously deployed version. It can restore code behaviour quickly, but it does not reverse writes made to databases, queues or other connected resources.
IN THIS ARTICLE
01 What you need before you begin
Identify the known working version and the current incident. Review configuration, bindings, secret changes and data compatibility before restoring older code, especially after a storage schema or Durable Object lifecycle change.
02 Roll back a failed Cloudflare Worker deployment
- Open Workers & Pages, select the Worker and go to Deployments.
- Compare the candidate version with the current deployment and confirm its required resources still exist.
- Open the candidate version’s action menu and choose Rollback, reviewing the deployment scope before confirming.
- Verify the active deployment and test critical routes, upstream integrations and error rates. A split deployment rollback directs traffic to the selected version as a single deployment.
- Record the incident, preserve the failed version for investigation and prepare a corrected release using a controlled deployment process.
03 Confirm the expected result
The intended previous version should handle traffic and reduce the observed failure. Check the application’s data and external side effects independently.
04 Troubleshoot unexpected results
Rollback can be restricted when required bound resources were deleted or a Durable Object lifecycle change occurred. An older version can also misinterpret newer data. Do not treat code rollback as a complete database recovery mechanism.
05 Example: reverse a Worker deployment without hiding the cause
Before rolling back, note the failing URL, time and version deployed. Keep a copy of the error or request identifier. This gives you evidence to investigate after service is restored rather than losing the connection between a change and its symptom.
Select the known-good version through the deployment workflow used for the Worker. Check its routes and bindings as well as the code. A previous code version can still fail if a database binding, secret or external service changed since that version last ran.
What should I test after rollback?
Request the affected route through the public hostname, then test any important write operation using a safe test record. Confirm authentication and response content, not only a successful HTTP status. Inspect current logs to verify the expected version receives the request.
Rollback does not necessarily reverse data written by the failed release. Review any external changes separately and avoid manually deleting data without a recovery plan. If you need our help with a hosting route behind the Worker, provide the origin hostname, affected path and observed result. Keep Worker secrets and authorisation headers out of the support message.
Will rollback undo messages already sent or records already changed?
No. Those effects belong to the connected systems. Investigate and repair them through their own recovery or compensating-action process.