How to Monitor App Uptime With Health Checks, Heartbeats, and Metrics

Effective application uptime monitoring requires three distinct signals: an external health endpoint poll, scheduled metrics tracking, and a dead-man heartbeat for cron or queue workers. A lightweight /health endpoint should only confirm whether an instance can accept work, avoiding expensive operations that could introduce noise or extra load. Rule-specific metrics — such as evaluation attempts, failures, and latency — should be tracked separately with low-cardinality labels like rule version and flag state to keep querying manageable. Each signal addresses a different failure mode, since a healthy web process running alongside a stopped background job still represents an unhealthy release. Silence in a metrics window is inherently ambiguous, as zero failures could indicate perfect execution or zero executions entirely.