Updated September 5, 2026
Describe the failure first
Record the URL, time, affected page, expected behavior, and actual result. Distinguish an incomplete deployment, an error response, a blank page, and a failed interaction. Preserve the first error and the latest change. Remove tokens, personal information, and database credentials before sharing logs.
Build failures: compare environments
Compare runtime versions, lockfiles, install commands, and build scripts between local and hosted environments. For missing modules, check dependency declarations and path capitalization before adding packages. Verify the project root and output directory when configuration is involved.
Runtime failures: inspect server logs
Check the start command, required environment variables, database permissions, and server errors. A generic error page is not a diagnosis. If the home page works but an API fails, inspect that request separately instead of rewriting the page.
Blank pages: inspect the browser
Use Console and Network to locate script exceptions and failed requests. Record status codes, paths, and reproduction steps. For example, an inner page that works through navigation but fails on refresh may need a routing configuration fix. Do not redirect every error to the home page.
Domain failures: compare with the preview
Request the same path on the preview and production domains. Verify project binding, the DNS target required by the platform, certificate readiness, and redirect loops. Do not repeatedly change DNS based on a single cached local result.
Give AI a useful error report
Supply the stack, runtime version, sanitized configuration, first error, reproduction steps, and recent changes. Ask for one testable hypothesis, a minimal change, and verification steps. Test one cause at a time. Record the cause and fix, not simply that redeployment happened to work.
Official reference: Vercel: Managing Deployments