Cron Schedules for Health Checks

Health check and uptime monitoring jobs are the safety net of production systems, and their scheduling frequency directly determines your maximum mean time to detection (MTTD) for outages. A health check running every 5 minutes means in the worst case an outage goes undetected for 4 minutes and 59 seconds before the next check fires and triggers an alert. For a payment processing system, that could mean thousands of failed transactions. Choosing the right check frequency requires balancing detection speed against the overhead of the checks themselves. This collection shows eight monitoring frequencies from every minute to every four hours. The every-minute check (* * * * *) is the finest granularity standard cron supports and is appropriate for critical business paths: payment endpoints, authentication services, and primary API gateways. Every 2 minutes (*/2 * * * *) and every 5 minutes (*/5 * * * *) are appropriate for secondary services and internal APIs. Every 10 minutes (*/10 * * * *) suits background services where brief unavailability doesn't immediately impact users. Hourly checks (0 * * * *) are appropriate for batch jobs and scheduled tasks that run infrequently anyway. SLA-driven frequency selection: if your service level agreement commits to 99.9% uptime (8.7 hours/year of allowed downtime), you want to detect outages within a few minutes. With a 5-minute check interval, you detect outages within 5 minutes on average (2.5 minutes on average), giving your team time to respond before the SLA breach window opens. The three-check alerting pattern reduces false positives: instead of alerting on the first failed health check (which might be a transient timeout), alert only when three consecutive checks fail. This pattern reduces on-call pager fatigue while still detecting real outages within three check intervals (3 × 5 minutes = 15 minutes for a 5-minute interval). Scheduling checks at multiple specific times: 0 9,13,17 * * 1-5 fires at 9 AM, 1 PM, and 5 PM on weekdays — a pattern for lighter-weight checks during key business moments (morning open, midday peak, end of business) without running continuously. This is useful for checks that are heavier (like full smoke test suites) that would be too expensive to run every minute. Real-world monitoring stack: combine cron-scheduled health checks (checking that the service responds) with log-based alerting (checking that the service is behaving correctly) for comprehensive coverage. Cron checks tell you the service is up; log monitoring tells you whether it's producing correct results. Tips: for sub-minute monitoring (every 30 seconds), standard cron cannot help — use a dedicated uptime monitoring service like Pingdom, UptimeRobot, or Better Stack that polls at sub-minute intervals and manages alerting, reporting, and status pages.

* * * * *
*/2 * * * *
*/5 * * * *
*/10 * * * *
0 * * * *
0 */4 * * *
0 9,13,17 * * 1-5
*/3 * * * *