Because a shallow /health endpoint only proves the app process is running, not that the feature works. A health route that just says the app is up will happily report healthy while the database read path behind it is dead. It is a shop with the OPEN sign lit but the till broken: looks fine from outside, sells nothing.
Probe the actual endpoint the way a user would, and check for a known marker in the response - not just a 200. If your API returns data, the probe should ask for data and confirm the expected content came back:
# Bad: pings a route that is always up
curl -sf https://api.example.com/health # 200 even if the DB is down
# Good: exercises the real path and checks a marker in the body
curl -sf https://api.example.com/query -d 'SELECT 1' | grep -q result
# non-zero exit -> alert. Fails when the FEATURE fails, not just when the process dies.Run it on a schedule from OUTSIDE the box (a cron, an uptime service), so you also catch network and edge failures, not only app crashes.
Two subtleties worth knowing. A fresh-connection health check can self-heal on contact: it opens a brand-new connection, which succeeds, and hides a connection-pool or lock problem that real, reused traffic is actually hitting. Probing the real path with a real query is what surfaces that healthy-but-broken class. And even a real-path probe only proves the endpoint answered for you, not that real callers are succeeding - it can read green while live traffic returns 5xx. So watch the status codes your actual callers get (from request logs or the CDN stream) as the complement to any liveness probe.
On an in-process engine this bites harder: a heavy DuckDB query can freeze the whole event loop, so even the health check stops responding. Where monitoring fits overall: https://www.tigzig.com/agents-faq/what-should-i-monitor-for-a-small-production-app. Full item: https://www.tigzig.com/security/monitoring.
← All Agents FAQ