Do I Need a Health Check Endpoint for My App?
5 min read
Do you need a health check endpoint for your beta? For most vibe-coded apps, yes, and it takes about five minutes. A health check is a tiny URL, usually /health or /api/health, that returns a simple "I'm alive" response. Its whole job is to give a monitoring service something cheap and reliable to poll so you find out your app is down before your users do.
Why people keep mentioning it
The reason a health check keeps coming up is that "is the site up?" is harder to answer automatically than it sounds. Your homepage might load fine while the database behind it is dead. An uptime monitor that just fetches your homepage can be fooled by a cached page, a redirect, or a heavy page that times out for unrelated reasons.
A health check endpoint sidesteps all of that. It is a route you control that does one small, honest thing and reports the result. Monitoring hits it every minute, and if it stops answering, or answers with an error, you get an alert.
Your AI agent almost certainly did not add one, because you never asked for a page nobody visits. It built the features you described. A health check is plumbing, invisible in the demo, so it got skipped.
How to check if you already have one
- Open your app's URL and add
/healthto the end, for examplehttps://yourapp.com/health. Try/api/healthtoo. - If you get a small text or JSON response like
OKor{"status":"ok"}, you already have one. Note the exact path. - If you get your app's 404 page, you do not have one yet. That is the common case and it is fine.
Also check your host. Some platforms (Railway, Render, Fly.io, AWS load balancers) ask for a health check path in their settings. If that field is blank or pointed at /, that is worth fixing too.
The fix: add a health route
The route should be fast, need no login, and touch as little as possible. In a Next.js app with the app router, create app/api/health/route.ts:
export async function GET() {
return Response.json({ status: "ok" });
}
That gives you https://yourapp.com/api/health. For Express or a plain Node server, the equivalent is one route:
app.get("/health", (req, res) => res.status(200).json({ status: "ok" }));
Then wire something to watch it:
- Point a free uptime monitor at the URL. UptimeRobot, Better Stack, or your host's built-in checks all work. Set the interval to one minute and add your email or phone for alerts.
- Tell your host about it. If your platform has a "health check path" setting, put your route there so it can restart the app when the check fails.
- Confirm the alert actually fires. Temporarily stop the app or point the monitor at a wrong path, and make sure you get the notification. An alert you never tested is not an alert.
If you want the check to mean more, have it try one real dependency, like a single lightweight database query, and return an error if that fails. Keep it minimal though. A health check that does heavy work becomes its own source of load and false alarms.
The trap to avoid
Do not make the health check verify everything. It is tempting to have it ping the database, the payment provider, the email service, and three APIs. When any one of those has a blip, your health check goes red and your phone buzzes at 3am for something that did not actually take your app down. A good check confirms the app is running and, at most, that its main database answers. Leave deep checks to your error tracking.
Where this fits
A health check is one of the smallest pieces of the difference between "it works when I test it" and "I will know within a minute if it stops working for real users." It pairs naturally with knowing when your app is broken for real users and, later, with a public status page for your beta. The free Readiness Report checks whether your app has a working health endpoint and whether anything is actually watching it, and the Finishing Pass sets up the route and the monitoring for you if you would rather not.