Know the moment your cron didn’t run.
Drumbeats parses your cron expression, computes the next expected run in your monitor’s timezone, and opens a MISSED incident the moment the schedule + grace period elapses without a ping. Three days of outage = one incident, not 288 emails.
How it works
Three steps. Less than a minute.
Create a cron monitor
Paste your cron expression and pick a timezone. Drumbeats parses 5-field and 6-field expressions; grace period defaults to 5 minutes.
Add one line to your script
`curl https://api.drumbeats.io/v1/ping/<id>` after the job. Add `/start` and `/failure` for full lifecycle tracking.
You hear about it before users do
A status detector runs every 30 seconds. MISSED, FAILED, DURATION_HIGH, and DURATION_LOW incidents route to Slack, Email, Telegram, Discord, browser push, or a webhook within seconds.
The actual product
Three views into one cron job
Real components, virtual data. Daily 9 AM job, three missed runs in the middle.
Reliability
Every expected run, every day, at a glance
The strip shows the last 30 daily runs. Green = ran on time, red = missed, amber = ran inside the grace window. Three consecutive misses look like an incident — and that's exactly what it is in Drumbeats: ONE incident, not three.
Schedule
Your cron, parsed — with timezone and tolerance
Drumbeats reads the same expression you have in your crontab and resolves it in your monitor's timezone. The next expected run is computed server-side, so a missed ping IS the signal — no polling, no guesswork.
- 5-field and 6-field expressions (with seconds) supported
- Per-monitor timezone — DST and offset shifts handled correctly
- Grace period defaults to 5 minutes; tunable per monitor
- Failure & schedule tolerances default to 1 — first miss alerts
Ping history
Every run, every payload, exportable
Each row is a START, SUCCESS, or FAILURE ping with run ID, duration, exit code, and any payload your script attached. Same table as the dashboard. One click downloads the lot as CSV.
Why cron is hard to monitor
Cron jobs fail in three modes — and only one shows up in your logs
Cron monitoring is a deceptively shallow problem. Engineers reach for it after the third "wait, that job never ran on Tuesday?" incident, find a Slack-webhook tutorial, wire it up, and ship something that works for the happy path. The trouble is that the happy-path failure mode — your cron command exits 1 and prints to stderr — is the rarest of the three things that actually break in production.
The two failure modes that cost real money are the silent ones. A schedule that drifts after a DST change, a `cron.d` file the package upgrade quietly replaced, a `*/5` interval that turns into a thirty-minute gap because the previous run hung. These never produce a non-zero exit code, never write to a log, never surface in any monitoring tool that watches for errors. They are visible only by their absence: the next expected run did not arrive.
Drumbeats inverts the model with heartbeat alerts for cron jobs: instead of waiting for an error event, every successful cron run sends a positive heartbeat. The schedule itself is parsed and tracked server-side — when the next expected run window passes (plus your configurable grace period), the absence of that ping IS the signal. Pair it with start/success pings and you also catch jobs that ran but never finished, jobs that finished but took twice as long as usual, and jobs that quietly returned an empty result set.
Missed runs (the silent killer)
A `cron.d` file your package upgrade replaced, a DST shift, a misnamed timezone. No log, no error — just nothing. Drumbeats fires a MISSED incident the moment the schedule + grace period elapses without a ping. If your service stays offline for a day, you get one incident, not one per missed run.
Partial / runaway durations
Last week the daily report ran in 90 seconds. Today it has been running for 40 minutes and the next scheduled invocation is starting on top of it. Set `min_duration_seconds` / `max_duration_seconds` and Drumbeats raises DURATION_LOW or DURATION_HIGH long before the pile-up causes downstream damage. A start ping with no matching success or failure inside the window auto-marks the run as FAILED.
Failed runs (exit ≠ 0)
POST `/failure` with the exit code, or pass `$?` on the command line. Drumbeats records the code, opens an incident on the first failure (or the Nth, if you raise `failure_tolerance`), and dispatches the alert via every channel you have configured — without you having to vendor an SDK or rebuild your alert routing per job.
Pair a cron monitor with an uptime monitor on the page that consumes the data the cron produces. That’s the complete picture: the backend pipeline, AND the customer-facing surface that depends on it.
One ping. You're done.
No SDK, no agent, no library. A single HTTP request is all it takes.
# In your crontab — append a curl ping after the job 0 9 * * * /opt/scripts/send-invoices.sh && curl -s https://api.drumbeats.io/v1/ping/YOUR_MONITOR_ID > /dev/null # Or wrap any command with start + end pings for duration tracking 0 2 * * * curl -s https://api.drumbeats.io/v1/ping/YOUR_MONITOR_ID/start > /dev/null \ && /opt/scripts/db-backup.sh \ && curl -s https://api.drumbeats.io/v1/ping/YOUR_MONITOR_ID > /dev/null
What does it cost?
What 200K Beats actually buys you
Free includes 200,000 Beats/month and 50 monitors. Each cron run is 1 Beat (or 2 if you use start + success/failure pings). 50 daily crons with simple pings = 1,500 Beats/month (30-day month) — under 1% of the budget. Bump to 50 every 15 minutes and you’re still inside Free at 144,000 Beats.
Outgrowing Free? Pro at $20/mo gets 1,000,000 Beats and 30-second intervals. Same plan also covers heartbeats, queue workers, and uptime checks — no separate product to buy.
Drumbeats vs. running a stack of single-purpose tools
Cronitor does cron. Healthchecks.io is heartbeat-only on the simple tier. Sentry Crons sit inside their APM. Drumbeats unifies all of it on one Beats budget — and Free is enough for many teams.
FAQ
Common questions
Your cron job just missed its 9 AM run. Would you know?
Most teams find out hours later — from their users. Drumbeats fires a MISSED incident the moment the schedule + grace period elapses, then routes the alert to Slack, Email, Telegram, Discord, browser push, or a webhook within seconds.
No credit card required · 50 monitors free · Setup in 60 seconds
Keep exploring
What to read next
Related monitoring
- Heartbeat monitoring
Same model for jobs that run on a fixed interval rather than a cron schedule.
- Background job monitoring
Async tasks and one-offs — track each run with start + success/failure pings.
- Public status pages
Turn any cron monitor into a customer-facing status page in one click.
- Incidents & alerts
Routing, escalation, and acknowledgement workflows for cron failures.
Free tools
- Cron expression generator
Build, validate, and explain any cron schedule with timezone support.
- Cron expression translator
Paste any cron expression and see what it actually runs and when.
- AI agent setup
Generate a paste-ready prompt for Cursor, Claude Code, Codex, or Windsurf.
Resources
- Drumbeats vs. Cronitor
A side-by-side comparison of pricing, features, and developer experience.
- Drumbeats vs. Healthchecks.io
How the two heartbeat-monitoring tools differ on price and depth.
- Pricing & Beats explainer
See how 50 daily cron jobs fit comfortably inside the Free plan.
- Full FAQ
49 deeper technical answers about pings, schemas, and edge cases.