Health Monitoring

Health monitoring via scheduled cron jobs—heartbeat pings, uptime checks, and liveness probes—is one of the oldest and most reliable patterns in systems operations. A cron job runs at a fixed interval, makes a lightweight request to a service endpoint, and alerts if the service fails to respond. This pattern underpins the monitoring infrastructure of millions of production services worldwide.

Types of Health Monitoring Cron Patterns

Simple Uptime Pings

• * * * * * — Every minute. Maximum cron resolution, ~30 second average MTTD. For critical customer-facing services.
• */5 * * * * — Every 5 minutes. The most commonly used health check interval, ~2.5 minute average MTTD.
• */10 * * * * — Every 10 minutes. Suitable for internal services.
• */30 * * * * — Every 30 minutes. Background services and data pipelines.

Heartbeat and Dead-Man's Switch Checks

A dead-man's switch inverts the usual model: instead of the monitor calling the service, the service calls the monitor at regular intervals. If the monitor does not receive a ping within the expected window, it raises an alert. This is particularly valuable for monitoring cron jobs themselves—if your nightly backup fails silently, a heartbeat check catches it.

Synthetic Transaction Monitoring

Beyond simple ping checks, synthetic monitoring validates that a complete user journey works end-to-end. A cron job at */15 * * * * might log into your application with a test account, complete a representative transaction, and report the outcome.

Common Use Cases

• SSL certificate expiry monitoring: A weekly job at 0 9 * * 1 checks certificate expiry dates for all production domains.
• API rate limit headroom: A periodic check at */30 * * * * monitors remaining quota and alerts before exhaustion.
• Disk space and resource monitoring: A job at */15 * * * * checks disk utilisation and file descriptor usage.

Best Practices for Health Monitoring Cron Jobs

• Keep checks fast and lightweight. Target sub-second check execution.
• Build in retry logic. Implement a 2-of-3 failure threshold before alerting.
• Check from multiple locations. True availability requires checking from multiple regions.
• Separate check intervals by criticality. Tier-1 (* * * * *), tier-2 (*/5 * * * *), tier-3 (*/30 * * * *).
• Test your monitoring pipeline. Deliberately take a service offline to verify alerts fire.