Rollback

A bad main deploy is reversed by deploying the previous SHA. Cloudflare Workers does not have a one-click “previous version” button; rollback is a re-deploy of the prior commit. Expect 1–3 minutes per Worker.

Decide first: roll forward, or rollback?

Symptom	Action
Single Worker is throwing, others healthy	Roll forward — git revert <bad-sha> + redeploy that Worker only.
Multiple Workers broken AND the bug looks structural	Rollback the whole main to the last green SHA.
Data corruption suspected (D1 or DO state)	STOP. Page the on-call — see incident response. Rolling back code may make recovery harder if the bad code already wrote bad state.
Stripe webhook signing or saga state broken	Same — page first; payments need a payment-team owner present.

Fast path — single Worker

1. Identify the last-known-good SHA on main. The Deploy workflow’s last green run is authoritative.
2. From the repo root, and from main, run:

   git checkout <last-good-sha>
   cd apps/<worker>
   npx wrangler deploy --env production

3. Verify with a curl against the Worker route (e.g. curl -i https://api.nowyourlink.com/healthz).
4. Return to main (git checkout main) and open a revert(<scope>): rollback <bad-sha> PR so the working tree matches what’s running.

Full path — every Worker

1. Identify the last-known-good SHA.
2. Run the Deploy workflow from the Actions tab against that SHA — set ref to the SHA (Actions → Deploy → Run workflow → Use workflow from <sha>).
3. The workflow re-applies Terraform’s app resources and re-deploys every Worker in the documented dependency order (web → api → admin → queue → cron → webhook).
4. Open the corresponding revert PR so the working tree matches production.

What you cannot rollback by re-deploying

• Terraform-managed resources whose state diverged. D1 schema migrations, R2 lifecycle rules, Queue topology — these are forward-only. The fix is a follow-up migration, not a rollback. If a migration is the cause, hold deploys until the down-migration is written + reviewed.
• Persisted Durable Object state. AuctionDO and the WS Hub DO retain their internal SQLite — rolling back code that wrote bad state leaves the bad state in place. Page payment-team / auction-team on-call.
• Stripe-side state. PaymentIntents, Customers, Subscriptions, Invoices created by the bad code persist. Use the Stripe dashboard to refund/void rather than expecting the rollback to undo them.

See also

• Deploy — the forward path
• Incident response — when to page
• Spec 05 — Payment Saga for saga-specific rollback caveats