First identify what needs recovering
Use this checklist when an app actually runs on Vercel, including exported AI-built apps. It is not a universal procedure for every builder's built-in hosting. Record the failing user journey and the last verified working deployment before choosing an action. A loaded homepage does not settle whether login, writes or uploads work.
Have the application owner decide how to handle writes accepted since the release. Reverting code is not permission to discard data, restore a database or reactivate customer-facing jobs.
Choose between rollback, restoration and rebuilding
| Target state | Candidate path | Evidence before approval |
|---|---|---|
| Retained, previously production | Review Instant Rollback eligibility. | Record target deployment ID, source revision, affected domains and owner approval. |
| Deleted, still recoverable | Review restoration before rollback eligibility. | Check Recently Deleted, recovery availability and the restored build before changing domains. |
| Permanently removed or unavailable | Prepare a rebuild from preserved source. | Reconcile dependencies and configuration; do not assume the new artifact equals the lost one. |
Instant Rollback targets deployments previously assigned to production. Hobby is limited to the immediately previous deployment; Pro and Enterprise can choose eligible older ones. Most preview deployments are not eligible. Retention alone does not make a preview production-ready; review manual promotionseparately.
The retention documentation protects deployments with production aliases and other exceptions. Successfully built, deleted deployments have a 30-day recovery period; unsuccessful builds may disappear sooner. Review Settings → Security → Recently Deleted. Restoration and traffic reassignment are separate decisions. After permanent removal, that artifact cannot be restored.
A storage policy is also a recovery decision
The October 9 notice announces a 30-day retention window for existing Pro teams, with cleanup starting October 23 unless they opt out. Shortening history reduces the set of retained recovery targets; it is not proof every old deployment is deleted. The older defaults table in the retention guide differs from this dated notice. Review the team email and effective project policy, rather than treating either page as proof of your account's settings.
Decide which working release you need to preserve and assign a review owner before a cleanup deadline. For billing rather than recovery, use the app budget worksheet. This guide does not change retention or purchase storage.
Preflight an eligible rollback
Vercel's rollback documentation says the old build keeps its environment configuration rather than receiving current project-setting values, and restores the old cron configuration. External databases and services require separate compatibility review.
- Pin the identities. Record team, project, current and target deployment IDs, source revisions and domains. Similar branch names do not prove the same artifact.
- Review dependencies. Ask maintainers whether the target can use current schema, API contracts and credential versions. Record secret identifiers or versions, never secret values.
- Review side effects. Identify scheduled jobs, payment actions, emails and webhooks. Stop when ownership or safe behavior is unknown.
- Approve the change. Agree on affected domains, observation window and failure response. An AI agent's recommendation is not approval to change production.
An authorized operator can then open the project's Production Deployment tile, select Instant Rollback, review the target and domains, and confirm. This is a documented route, not a button we have tested in your account. Keep unexpected targets or permissions UNVERIFIED.
Verify recovery before resuming normal publishing
Collect fresh evidence from the custom domain: expected release, critical routes, login and approved harmless data checks. Review errors and jobs separately. A dashboard success message or HTTP 200 alone does not prove the original problem is resolved.
Vercel disables production-domain auto-assignment after rollback. Its Undo Rollback flow promotes a chosen deployment and re-enables assignment. Review and approve that target before resuming; committing a fix alone is not live verification.
If rebuilding is necessary, preserve the original source revision, lockfile and configuration references. Validate the new artifact before promotion. Changed dependencies or missing configuration can make an old commit produce different behavior; reproduction stays UNKNOWN until checked.
Copyable recovery record
Keep this in your own incident notes. Do not send credentials or customer data to us.
- Project / owner / failing journey / observation time: __________
- Current and target deployment IDs / source revisions / domains: __________
- Retained / recoverable / rebuild required / evidence: __________
- Retention policy / applicable exception / review deadline: __________
- Data compatibility / credential references / external-job owner: __________
- Approved action / verification results / failure response: __________
- Undo Rollback target / approval / subsequent live release: __________
Moving to a different host is a separate task: use the export and migration inventory. If the app uses Supabase, its database backup checklist covers a different recovery layer; do not perform a database restore merely because you rolled back the web app.