Updated September 5, 2026
Keep a recovery point
Record the working commit and deployment URL. Code, databases, uploaded files, and environment configuration are separate recovery objects. A Git repository is not a complete backup. Before touching real data, confirm the backup location, permissions, and restore procedure.
Verify changes in a preview
Keep each update scoped and test key pages and real user paths such as login and forms. Validate database changes in an isolated test environment. Do not let a preview write directly into production data. Publish only after verification.
Limit the impact of a failure
Preserve the failed version, time, logs, and affected features. Pause operations involving incorrect charges or data corruption and involve the responsible operator. Avoid repeatedly pushing AI-generated fixes without a diagnosis: it makes the last working state harder to identify.
Code rollback is not data rollback
Before restoring an older deployment, verify that it works with the current database and configuration. Vercel can repoint domains to a selected deployment, but do not assume this restores databases, external services, or environment settings. Confirm data recovery separately to avoid overwriting valid records created after the incident.
Verify recovery on the production domain
Check the home page, important inner pages, key interactions, and error logs. Verify that the domain serves the intended version and that data writes work correctly. Document the cause and tests before publishing the fixed version so the failure does not return.
Keep a lightweight maintenance record
For every update, record the date, commit, deployment URL, scope, reviewer, and rollback target. Periodically verify that backups can be restored, dependencies are maintained, and domain and service billing remain healthy. Choose a review frequency appropriate to the risk and usage of the site.
Official reference: Vercel: Instant Rollback