Free tool
Vercel deployment broken? Collect the evidence first
Your deployment is broken and the pressure is on. The usual reflex is to redeploy, change a setting, and hope. That wastes time, and it often destroys the evidence you need.
This free checklist does the opposite. Pick what you see, collect the five things that matter for that symptom, and get a clean summary you can paste into an issue, a chat with your team, or a message to a developer. It runs entirely in your browser. Nothing is sent anywhere.
Short answer
- Do not redeploy blindly. A new deployment can hide the logs of the one that failed.
- Build fails? Start with the full build log and compare the Node.js version with your local machine.
- Build works, site breaks? Look at the runtime logs and the Production environment variables.
- Works locally only? Check upper/lower case in file paths: Vercel builds on Linux, which is case-sensitive.
The checklist
Choose a symptom, tick the evidence you have, and fill in what you know. The summary updates as you type. Anything that looks like a key, token, password or connection string is removed from the summary automatically, but always check before you share it.
4. Your summary
DEPLOYMENT INCIDENT SUMMARY Symptom: The build fails URL: - Changed just before: - Expected: - Actual: - Already tried: - Error message: - Evidence: [ ] Full build log of the failing deployment [ ] Last deployment that worked, and the commits since then [ ] Node.js version in the Vercel project settings vs. local (node -v) [ ] Does the build command also fail locally? [ ] Lockfile committed and matching the package manager Made with dimensa.dev/en/vercel-deployment-checklist
Nothing leaves your browser. Keys, tokens and passwords that look like secrets are removed automatically. Still check before you share.
Why evidence first
Most deployment problems live in one layer: the build, the runtime, the configuration, an external service, or the browser. The symptoms overlap, so guessing the layer is slow. Five pieces of evidence usually point straight at it.
A clean summary also saves time when you ask for help. Whoever helps you, a colleague or an outside developer, can start with the facts instead of twenty questions. That is the same way we work: we first prove where a problem is, then change code.
What to do with the summary
Paste it into your issue tracker or team chat, or keep it as a log of what you checked. If you want us to look at it, request a quote and paste the summary into the message field. We reply with what we see and what the fix takes.
Want us to look at it?
Request a quote and paste your summary into the message. We first prove where the problem is, then tell you what the fix takes.
Please do not send passwords or API keys. If we need access, we arrange that safely.
FAQ
Frequently asked questions
Is my data sent anywhere when I use this checklist?
No. The checklist runs in your browser. It sends no requests and stores nothing. Only you decide where the summary goes.
Why does my Next.js app work locally but fail on Vercel?
The most common causes are missing Production environment variables, file paths with different upper/lower case, and code that reads local files at runtime. Test a production build locally and compare the variable names.
Where do I find the logs of a failed Vercel deployment?
Open the deployment in your Vercel dashboard. The build log is on the deployment itself; errors while the site is running are in the runtime logs, which you can filter by path.
Should I just redeploy?
Only after you have the evidence. A redeploy sometimes works by accident, and then you still do not know the cause. Save the build log and the failing request first.