Capture one repeatable failure
Write down the URL, action, expected outcome and approximate time. Try once in a fresh browser session. Keep the release version or commit so you know exactly which code you're investigating.
Check browser errors for the screen and network request; check deployment logs for the build; check server logs for the request that failed. Redact tokens, private customer data and credentials before sharing any evidence.
If the deployment never finishes
Do not replace your lockfile or upgrade everything as a first response. Reproduce the failure with the same inputs, change one cause and keep a record of what changed.
- Read the first meaningful build error, rather than only the final ‘failed’ line.
- Compare the Node or runtime version and the package manager with the working setup.
- Install from the committed lockfile and run the production build locally.
- Check the configured working directory, build command and output target against the framework.
- Look for files that exist locally but were never committed, including case mismatches in imports.
If the page loads but a feature fails
- Blank screen: inspect the browser's first error and failed asset requests.
- API failure: check its URL, status code and matching server log. A browser must not call your laptop's localhost endpoint.
- Login loop: compare the production site URL, callback URL and cookie settings with the auth provider.
- Missing records: confirm the database environment and migrations, then test the current user's permissions.
- Refresh gives a 404: check how your host routes direct requests to nested pages.
- Uploads disappear: confirm files go to persistent storage, not a temporary server filesystem.
Prove the fix on the public URL
Repeat the original steps after deployment, then test the nearest related journeys. For a login fix, that might include a new account, an existing account and signing out. Check logs for the outcome rather than relying only on a toast.
If a release is actively disrupting customers, consider returning to a known working version while investigating. Check database compatibility first. Keep a short incident note so the next release includes a check for this failure.
A few fair questions.
Why does the development command work but the build fail?
Development and production can use different compilation paths and settings. A production build may catch missing imports, environment assumptions or unsupported runtime features that your development session did not exercise.
Can I send the error to my coding assistant?
Yes, after removing credentials and private data. Include the relevant command, environment and reproduction steps. Ask for a specific hypothesis and verification step before approving broad changes.
Will switching hosts fix it?
Only if the hosting mismatch is the cause. A bad API URL, missing setting or broken permission rule can follow the app to a new host. Diagnose the failing part first.