Cron job monitoring
Get alerted when a cron job doesn't run
Give us the same cron expression your job runs on and the timezone it runs in. Your job pings a unique URL at each scheduled time. Miss a run and we open an incident and alert you, before anyone has to notice the output never showed up.
# billing run · weekdays 02:30
30
min
2
hour
*
dom
*
mon
1-5
dow
America/New_York · 10 minute grace period
How it works
Your crontab, mirrored as a monitor
Create a cron monitor with your cron expression and timezone, and append the monitor's ping URL to the job. Each successful ping tells us the job ran; we then compute the next scheduled time straight from your expression.
If that next tick passes (plus the grace period) without a ping, we open an incident and alert you. The next successful ping resolves it. Same incidents, alerting and history as every other monitor type.
- Standard 5-field cron expressions
- Next-due time computed in your timezone
- Grace period absorbs normal start-time drift
Run history
Mon 02:30 EST
Ping received 4s after the tick
Tue 02:30 EST
Ping received 12s after the tick
Wed 02:30 EST
Thu 02:30 EST
Next expected run
30 2 * * 1-5 /opt/billing.sh \ && curl -fsS https://sentinel.sh/ping/abc123
Features
Scheduled jobs, watched on schedule
Matches your crontab
Enter the same cron expression your job already runs on. We compute exactly when the next ping is due: `*/15 * * * *`, `0 3 * * *`, `30 2 * * 1` all just work.
Timezone-aware scheduling
A job scheduled for 3am should be due at 3am in its own timezone. Set the timezone once and we evaluate the schedule against it, with no UTC math and no DST surprises.
Missed-run and failure alerts
No ping by the next scheduled tick plus your grace period? We open an incident and alert every channel you use. Report a failed run explicitly with ?status=fail.
Why it matters
Crons fail quietly by design
A scheduler that fails to fire, a server reboot that drops the cron, a syntax error that skips the job: none of them raise an alarm on their own. Mirroring the schedule means a skipped run is caught the moment it's late.
5-field
Standard cron expressions, the same ones in your crontab
per-tz
Schedule evaluated in the timezone you choose
push
Outbound only: your job pings us, nothing to expose
+ grace
A grace window absorbs normal start-time drift
Billing and invoicing
A billing run that silently skips a night is real money and angry customers. Tie the schedule to the monitor and know the same morning, not at month-end.
Reports and digests
Weekly reports and daily digests are noticed only when they don't arrive. Catch a missed generation run before a client emails asking where their report is.
Maintenance and cleanup
Log rotation, cache pruning, certificate renewals, database vacuuming: the housekeeping jobs whose absence only surfaces as a much bigger problem later.
How is cron monitoring different from heartbeat monitoring?
They share the same push-based mechanism: your job pings a URL and a missing ping triggers an alert. The difference is how 'on time' is defined. A heartbeat monitor expects a ping every fixed interval (e.g. every 15 minutes). A cron monitor expects a ping according to a cron expression, so it lines up exactly with a job in your crontab, including irregular schedules like 'weekdays at 2:30am'.
What cron expressions are supported?
Standard 5-field cron expressions: minute, hour, day-of-month, month, day-of-week, the same syntax your system crontab uses. Use the exact expression your job runs on and set the timezone to match, and the expected ping times will align with your actual schedule.
How does the timezone setting work?
Cron schedules are evaluated in the timezone you pick for the monitor. So `0 3 * * *` with timezone America/New_York expects a ping at 3am Eastern, and the next-due time shifts correctly across daylight saving changes, so you don't have to translate your schedule into UTC.
What happens when a run is missed?
After each successful ping we compute the next scheduled time from your cron expression. If that time plus your grace period passes without a ping, we open an incident and notify you. The next successful ping resolves it. You can also hit the ping URL with ?status=fail to open an incident the moment a run fails.
Do I need to change my cron job much?
Just append a single curl to the command so it runs after your job succeeds, for example `0 3 * * * /opt/job.sh && curl -fsS https://…/ping/token`. No agent, no inbound firewall rules, nothing to install.
Is cron monitoring available on the free plan?
Cron (and heartbeat) monitoring is available on the Basic plan and above, alongside ping, port, DNS and domain monitoring. The free plan covers HTTP/HTTPS uptime and JSON response assertions.
Watch every job in your crontab
Mirror your schedule, append one curl, and let Sentinel catch the runs that don't happen.
No card for the free plan · 14-day trial on paid plans · Cancel anytime