Why it happens
A build proves the code compiles and nothing more. At runtime, a missing variable, a database the new code cannot reach, or a migration that never ran brings it down on the first request.
How to tell
- 5xx on the five-minute check, straight after the deploy.
- The host's logs show the first request's error, which is nearly always a variable or a connection.
- Journeys fail at the first page.
The fix
- Read the first runtime error in the host's logs.
- Roll back if customers are waiting; fix forward if not.
- Add a health route that checks the database and the required configuration, and have the host wait on it before switching traffic to a new deploy.
The prompt for your builder
Paste this into Lovable, Bolt, Cursor, Claude Code or whatever built the app. Replace anything in capitals. It never asks you to paste a secret into a chat; keys go into your host’s environment, by you.
Add a /api/health route to my app that checks the database connection and every required environment variable, returns 200 with a short JSON status or 503 naming what is missing, and configure my host to use it as the deploy health check so a broken deploy never receives traffic.
How Keelnest catches it
The site check runs every five minutes and opens a critical incident after the failure is seen on two consecutive checks, so a single blip never pages anyone. Publish Verification ties the failure to the deploy that caused it.
Know the moment this happens.
Keelnest watches your production app every five minutes and tells you in plain English what broke — with the fix. Free for your first app.