Choose a recovery action from the failure evidence. A source correction, Worker-version rollback, Terraform state recovery, and application-data restore are different operations.
| Situation | Supported response |
|---|---|
| Transient failure with the intended code and compatible state | Retry failed jobs from the same release run while its package exists |
| Wrong application code or configuration | Prepare a reviewed correction or source revert on current main |
| Database or storage incompatibility | Design a compatible forward correction and a separate data-recovery procedure |
| Missing or damaged Terraform state | Follow the canonical R2 recovery runbook |
-
Inspect the failed job, earlier deployment receipts, and pending production runs. Confirm that retrying this commit still matches the desired state. A newer successful release makes an older retry unsafe by default.
-
If the failure is transient, use Re-run failed jobs on the same GitHub Actions run. Existing app packages are retained for seven days. Deployment retries reuse those packages, but preparation, migrations, and smoke checks execute again.
-
If the package has expired, a full rerun must rebuild and verify it. Confirm the old commit is still intended before doing so; otherwise use a new corrective pull request. Do not upload an arbitrary local build as a substitute for the missing release artifact.
-
Check every affected app's receipts and health evidence, including consumers that experienced the partial release.
-
Identify the last known-good behavior from release records and user-facing checks. Inspect changes since that release, including migrations, bindings, secrets, shared packages, and consumers. Earlier code must understand the data and resources that exist now.
-
Create a corrective branch from current
main. Revert the specific faulty change or restore only reviewed files from a known-good commit. Retain already-applied migration history, current resource ownership, and unrelated changes. A whole-repository reset is not an application rollback. -
Add a compatible fix when the old code cannot read the current schema. Existing D1 migrations do not run backward when source is reverted. Durable Object state and queued work also survive application-code changes.
-
Follow Validate a change and Deploy a change. The correction receives a new commit and deployment record. Verify the original failing journey before declaring recovery complete.
Cloudflare supports Worker-version rollbacks, but the repository does not provide an authorized workflow to select and restore an old Worker version. A dashboard or workstation rollback is not part of the normal StormTrust release procedure. Multi-Worker releases also have no atomic rollback mechanism.
Cloudflare rollbacks do not restore connected resource data. Resource changes and Durable Object lifecycle changes can prevent a rollback. Review those constraints before implementing a dedicated recovery workflow.
For state loss, use the R2 backend recovery runbook ↗. It is the repository's break-glass exception to workstation applies. The repository does not implement scheduled full-state backups. Retained imports and the historical archive are not a complete disaster-recovery system. Application D1 and R2 data need their own backup and restoration procedures.