Rolling Back a Production Deployment

Use this guide to recover from a bad production deployment. You'll roll back to restore service, investigate the root cause, and deploy a fix.

Use this block when you already know what you're doing and want the full command sequence. Use the steps below for context and checks.

# 1. Confirm the problem
vercel logs --environment production --status-code 5xx --since 30m
 
# 2. Roll back immediately to restore service
vercel rollback
vercel rollback status
 
# 3. Verify service is restored
vercel logs --environment production --status-code 5xx --since 5m
 
# 4. Identify the bad deployment
vercel list --prod
vercel inspect <bad-deployment-url>
 
# 5. Check build logs for clues
vercel inspect <bad-deployment-url> --logs
 
# 6. Compare error logs between good and bad deployments
vercel logs --deployment <bad-deployment-id> --level error --expand
vercel logs --deployment <good-deployment-id> --level error --expand
 
# IF the cause spans multiple deployments, binary-search with bisect:
vercel bisect --good <good-deployment-url> --bad <bad-deployment-url>
# OR automate bisect with a test script (exit 0 = good, non-zero = bad, 125 = skip):
vercel bisect --good <good-deployment-url> --bad <bad-deployment-url> --run ./test.sh
 
# 7. Fix and deploy a preview
vercel deploy
vercel curl /affected-route --deployment <preview-url>
vercel logs --deployment <preview-deployment-id> --level error
 
# 8. Ship to production
vercel deploy --prod
vercel logs --environment production --status-code 5xx --since 5m
 
# ALTERNATIVE to redeploying: promote an existing good deployment directly
vercel promote <deployment-url>
vercel promote status

Before rolling back, verify that the current production deployment is actually broken. Check for errors in production logs:

vercel logs --environment production --status-code 5xx --since 30m

If you're seeing a spike in errors or user reports, move to the next step.

When production is broken, restoring service is the priority. Roll back to the previous production deployment:

vercel rollback

This instantly points production traffic to your previous deployment without rebuilding. The rollback happens at the routing layer, so it takes effect within seconds.

To verify the rollback completed:

vercel rollback status

Confirm that the rollback resolved the issue by checking production logs again:

vercel logs --environment production --status-code 5xx --since 5m

If the error count has dropped, service is restored and you can investigate at your own pace.

List recent production deployments to find the one that caused the issue:

vercel list --prod

This shows deployment URLs, timestamps, and the git commits that triggered them. Identify the deployment that was serving traffic when the errors started.

To see full details about that deployment:

vercel inspect <bad-deployment-url>

This shows the git commit SHA, branch, build time, and other metadata.

Sometimes the issue is visible in the build output. Check the build logs for warnings or errors that were missed:

vercel inspect <bad-deployment-url> --logs

Look for deprecation warnings, missing environment variables, or build-time errors that didn't block the deployment but affected runtime behavior.

If the cause isn't obvious, compare error logs between the good and bad deployments:

vercel logs --deployment <bad-deployment-id> --level error --expand

vercel logs --deployment <good-deployment-id> --level error --expand

The difference in error patterns between the two deployments narrows down what changed.

If several deployments went out between the last known good state and the broken one, use vercel bisect to binary-search through them:

vercel bisect --good <good-deployment-url> --bad <bad-deployment-url>

This walks through deployments one at a time, letting you check each one and mark it as good or bad. It finds the exact deployment that introduced the regression.

To automate the bisect with a test script:

vercel bisect --good <good-deployment-url> --bad <bad-deployment-url> --run ./test.sh

The script receives the deployment URL as an argument. Exit code 0 means good, non-zero means bad, and 125 means skip.

Once you've identified the root cause, make the fix locally and deploy a preview:

vercel deploy

Verify the fix against the preview deployment:

vercel curl /affected-route --deployment <preview-url>

Check that no errors appear in the preview logs:

vercel logs --deployment <preview-deployment-id> --level error

When the fix passes verification, deploy to production:

vercel deploy --prod

Confirm the fix is working in production:

vercel logs --environment production --status-code 5xx --since 5m

If you're on the Pro or Enterprise plan and need to roll back to a specific older deployment rather than just the previous one:

vercel rollback <deployment-url>

You can also use vercel promote to promote any existing deployment to production:

vercel promote <deployment-url>

To check the promotion status:

vercel promote status

• vercel rollback
• vercel promote
• vercel bisect
• vercel inspect
• Instant Rollback
• Debugging production 500 errors