Monitoring · Available on All tiers

Know when the cron job stops running — not just when the server does.

A dead-man's-switch for scheduled jobs: your job pings a unique URL after each successful run, and UptimeLuna alerts if that ping doesn't arrive on schedule.

Start Free → See pricing

Free forever plan, no card required.

Why it matters

Heartbeat monitoring

A cron job that silently stops running is one of the sneakiest outages there is — the server's fine, the process exits cleanly, nothing throws an error. The nightly backup just stops happening, and nobody knows until the restore fails. That's the cruelest part: the failure is invisible for exactly as long as nobody needs the thing the job was quietly protecting. A backup that stopped running six weeks ago looks identical to one running perfectly, right up until a server dies and the restore comes up empty. The same goes for a scheduled report that stopped generating, or a data sync that silently broke — nothing about your infrastructure looks unhealthy, because the thing that broke was a job, not a server. A heartbeat monitor is the only way to know a job stopped running for the same reason a person would: because it stopped checking in. It's the on-call equivalent of a job quitting without telling anyone — everything looks fine on paper until someone actually needs the output. The failure only becomes visible at the worst possible moment — right when you actually needed the thing that quietly stopped happening.

No runner or probe needed

Your job reports in itself, instead of UptimeLuna guessing at its status from the outside. That flips the usual monitoring model on its head — rather than trying to infer whether a background process ran correctly by probing something external, the job tells you directly, the same way it would tell a log file or a monitoring dashboard it already writes to. It's a small change to a job's own script, and it closes a blind spot no external probe ever could. It works the same way regardless of what language or platform the job itself is written in.

Grace period built in

A configurable buffer absorbs ordinary jitter without crying wolf on a job that just ran a bit late. A nightly job that usually finishes at 2am but occasionally runs until 2:10 because of a slightly larger dataset that day shouldn't trigger an alert every time — the grace period is exactly the slack needed to tell "a bit late" from "actually didn't run." Getting that buffer right is usually a matter of watching a job's normal run times for a week or two. It's a small setting that saves a lot of unnecessary 3am pages over time.

Perfect for the invisible stuff

Backups, ETL jobs, scheduled reports — anything that should check in but doesn't expose an endpoint to ping. These are exactly the processes a normal uptime check can't see, because there's no URL to hit and no port to probe; heartbeat monitoring is built specifically for the class of failure every other check type misses entirely. If it doesn't expose a URL or a port, heartbeat monitoring is very likely the only way to actually watch it. It closes a genuine gap that every other monitoring approach on this page simply can't reach.

FAQ

Heartbeat monitoring, answered.

Does UptimeLuna need to reach my job directly?

No — it's the reverse. Your job pings a unique URL after each successful run, and UptimeLuna alerts if that ping doesn't arrive on schedule, so nothing needs to be reachable from the outside. That also means it works for jobs running on a private network or behind a firewall, since only an outbound request is required, not an inbound one. That also makes it a natural fit for jobs running on infrastructure you don't want exposed to the public internet at all. That's a meaningful advantage for anything running somewhere UptimeLuna could never otherwise reach.

What if my job runs a bit late sometimes?

A configurable grace period absorbs ordinary jitter, so a job that finishes a few minutes late doesn't trigger a false alert. You set the buffer based on how much natural variance your job actually has — tight for something that should run like clockwork, looser for a job whose runtime depends on how much data it's processing that day. Tightening the buffer later, once you trust the job's normal timing, is just as easy as loosening it now. It's worth revisiting occasionally as a job's typical runtime shifts.

Can I monitor more than one scheduled job?

Yes — each heartbeat monitor gets its own unique check-in URL, so a backup job, an ETL pipeline and a scheduled report can each have their own monitor with its own schedule and grace period, rather than being lumped together under one generic "are my cron jobs okay" check. Naming each monitor after the job it watches makes it obvious at a glance which one just went quiet. Each one can be tuned independently, since not every job runs on the same schedule.

Get Started

Heartbeat monitoring. Free, starting now.

Start Free →