Cron Monitoring Guide
A practical reliability guide for teams that rely on scheduled work.
Cron Monitoring Guide from Sandglass: practical guidance for catching background jobs that stop reporting success even though no customer is watching the job directly.
What this guide covers
This guide focuses on catching background jobs that stop reporting success even though no customer is watching the job directly. The goal is to make the operating decision clear before a stressful incident forces the team to improvise.
- Heartbeat after the work succeeds, not when the job starts.
- A grace period absorbs normal scheduling jitter.
- A missing signal, not an error, is what should page you.
How Sandglass supports the practice
Add a heartbeat at the end of each scheduled job, set the expected interval with a small delay buffer, and alert when the heartbeat goes missing. Sandglass supports the continuous side of this work with checks, incidents, alert routing, and public status visibility.
- Back the practices here with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks.
- Route incidents to email, Slack webhook channels, and generic webhooks so the right people respond fast.
- Use a public status page to keep customers informed while the team works the incident.
Common mistakes to avoid
Checking that a scheduler exists is not enough. The useful signal is whether the actual job completed and reported back after its critical work finished.
Implementation checklist
Step 1: Start from customer impact
Decide which failures in this topic actually reach customers before adding any monitoring.
Step 2: Choose one signal per risk
Match each risk to a single HTTP, content, TCP, SSL certificate, or heartbeat check instead of stacking duplicates.
Step 3: Assign an owner and a channel
Give each alert one owner and one destination — email, a Slack webhook, or a generic webhook.
Step 4: Review after real incidents
Revisit intervals, thresholds, and ownership once a real incident shows what was missing.