FAQ

What is cron job monitoring?

Cron job monitoring is the practice of confirming that a scheduled task actually ran, finished, and produced the result it was supposed to. It typically uses a small "heartbeat" HTTP request from the job to a monitoring service. If the heartbeat does not arrive within an expected window, the monitoring service opens an incident and alerts you. It is distinct from generic uptime monitoring, which checks that a URL responds — cron monitoring asks the inverse question: did something happen that should have happened?

How do I monitor a cron job that runs every 5 minutes?

Create a heartbeat monitor with a 5-minute interval and a small grace period (60 seconds is a sensible default). Each successful run of your job sends a single HTTP POST to the unique heartbeat URL the monitoring service gives you. If the next ping does not arrive within interval + grace, an incident opens. The same pattern works for any cadence — 30 seconds, hourly, daily, monthly — by adjusting the interval and grace.

What is the difference between cron job monitoring and uptime monitoring?

Uptime monitoring asks "is this URL responding?" by making outbound requests to your service. Cron monitoring inverts that: your job makes a request to the monitoring service after it succeeds. The two solve different problems and most production teams need both. A cron monitor is the only way to detect a job that silently failed to run at all — uptime checks cannot see something that does not exist.

Do I need cron monitoring if my jobs run inside Kubernetes?

Yes. Kubernetes CronJobs solve scheduling and retry, but they do not solve "is this still doing the right thing in production at 3 a.m.?" A Kubernetes CronJob will happily mark a pod as succeeded when the script exits 0 even if the underlying work — a backup, a report, a sync — produced nothing useful. Heartbeat monitoring is the layer that asks the work itself to confirm success.

What happens when my cron job is genuinely down for maintenance?

Most heartbeat monitoring tools, including ours, support pausing a monitor for planned maintenance windows. You can pause via the dashboard, the API, or a CLI in your deploy pipeline. When paused, missed pings do not generate incidents. Resume the monitor when maintenance is over and normal alerting picks up from the next expected ping.

How do I keep my heartbeat URL secret?

Treat the heartbeat URL like a password. Do not commit it to a public repo, do not log it in plain text, and do not put it in client-side code. Mature monitoring services give you a way to rotate the URL if it leaks, and store only a hash of the token server-side so that even a database leak on the vendor side does not expose live URLs. If you ship through CI, inject the URL via your secret store rather than baking it into the script.

Can I monitor jobs running on serverless platforms like Vercel or Cloudflare?

Yes, and the pattern is identical. The serverless scheduler invokes your function on a schedule; your function ends with a single HTTP request to the heartbeat URL. The monitoring service does not need to know anything about how the function is hosted. Some teams prefer a wrapper utility that POSTs the heartbeat after their main logic completes, so the heartbeat ships only on success, not on partial failure.