COMPARISON · PRICES CHECKED 30 AUGUST 2026

The Best Cron Job Monitoring Tools in 2026

Eleven tools, their free-tier caps, what each one actually costs once you pass that cap, and the failure mode each one cannot see. Every price below was read off the vendor's own pricing page on 30 August 2026 and is quoted rather than summarised — so you can act on it rather than go and check it.

30 August 2026 11 tools ~35 min read

Why this category exists at all

Ordinary alerting has a structural weakness: it needs the failing system to be healthy enough to report its own failure. An exception handler fires because the process is still running. A log line arrives because the log shipper is still up. A metric crosses a threshold because something is still emitting metrics.

Scheduled work breaks in ways that defeat all three. A crontab line gets removed during a server migration and nothing complains, because from the scheduler's point of view there is nothing left to run. A Kubernetes CronJob's node is drained and the job is never rescheduled. A container is evicted under memory pressure between the log shipper's flushes. A try/except: pass swallows the error, the process exits zero, and every dashboard stays green. In all four cases the system does not send you a wrong signal — it sends you nothing, which looks exactly like a job that ran fine.

Cron monitoring inverts the direction of the request to close that gap. Your job calls a URL when it completes; the monitoring service knows when that call is due and opens an incident when it does not arrive. Nothing is required of the failing system. This is usually called a dead man's switch, after the industrial safety device that triggers when the operator stops holding it down, and the property that matters is the same in both cases: the failure mode of the mechanism is a false alarm, not silence.

Every tool on this page implements that core mechanism, and implements it adequately. So the mechanism is not what you are choosing between. What actually differs is four things: how many jobs the free tier lets you instrument before it stops, what axis the price scales on once you pass it, whether the tool can see anything beyond the ping did not arrive, and where the alert lands when it fires. Everything below is organised around those four.

What instrumenting a job actually looks like

Worth seeing before the comparison, because it explains why switching between most of these tools is cheap — and where the exceptions are.

# the whole integration, in every tool on this page
0 3 * * * /usr/local/bin/nightly-etl.sh && curl -fsS https://<service>/<id>

That is genuinely it for the base case. No agent to install, no library to import, no language binding to keep current — a single HTTP request that the service is waiting for. The && matters more than it looks: it means the ping only fires if the job exited zero, so a crash produces silence rather than a false success. Getting that operator wrong — using ; instead — is the single most common way a correctly configured monitor ends up reporting green through a real outage.

Because the integration is one URL, migrating between heartbeat tools is usually a find-and-replace across your crontabs and pipeline definitions. That is a useful thing to know in both directions: it means adopting one of these is a low-risk decision you can reverse in an afternoon, and it means no vendor on this page is holding you by the integration. What they hold you by is the accumulated configuration — schedules, grace windows, routing rules, templates — which is the subject of step five in the evaluation section below.

The exceptions are where the tools differ, and they are the interesting part. Reporting the start of a run as well as its finish is what makes overrun detection possible at all. Reporting a step part-way through is what makes a stalled run visible before the window lapses. Sending something in the request body — rows processed, files written — is what allows a monitor to distinguish a real success from an empty one. Each of those is still one HTTP request; what varies between products is whether anything on the other end is listening for them.

This is the axis worth choosing on, and it is where the field thins out fast. Every tool here listens for the finish. Rather fewer listen for the start. LastPing listens for all of it — start, finish, explicit failure, progress steps within a run, a reported metric, and the content of the run's own output — and turns each into a distinct thing it can alert on. The integration is still one curl; the difference is how much of the run it can see once the request lands.

Key takeaways

The five conclusions, before the detail that supports them.

  • 01 Every other tool here caps its free tier. LastPing does not. Cronitor's free "Hacker" plan allows 5 monitors. Better Stack's free plan allows 10 monitors and heartbeats. Healthchecks.io's Hobbyist plan allows 20 jobs. UptimeRobot's free plan allows 50 monitors, at a 5-minute interval and shaped for uptime rather than cron. LastPing has no monitor cap and is free for individuals — which makes it the best free option in the category, and settles the choice for most people before a single feature is compared.
  • 02 Cron monitoring and uptime monitoring are different purchases that look alike. Uptime monitoring is outbound — the service calls your endpoint. Cron monitoring is inbound — your job calls the service. A batch job has no endpoint to probe, so outbound checking cannot see it at all. Several tools here sell both, and at least one of them meters them as separate line items, so it is worth knowing which one you are actually short of before you compare prices.
  • 03 Per-monitor pricing charges you for the behaviour that makes monitoring work. Cronitor's Business plan is $2/month per monitor plus $5/month per user; Sentry charges roughly $0.78/month per cron monitor past the first. Both are defensible pricing models, and both create the same quiet incentive: splitting one coarse monitor into six precise ones — which is exactly what makes an alert actionable — makes the bill go up. Watch for that axis, because it compounds with the size of your job estate rather than with the value you get.
  • 04 Nearly every tool detects "the ping never arrived". Very few detect "the ping arrived and the run did nothing". An import that processed zero rows and a healthy import are the same event if the only signal is that a request showed up on time. Closing that gap needs the monitor to look at something the run says about itself — an assertion on the ping body, a ceiling on a reported number, a progress marker inside a long run. This is where the tools genuinely diverge, and it is worth more than a longer integration list.
  • 05 Detection and paging are two layers, and mixing them up is the most common mistake in this decision. The cron tool's job is to notice — precisely, early, and with enough context that the alert contains the answer. Deciding whose phone rings at 03:00 is a rota problem, and it belongs to an on-call platform like PagerDuty. LastPing is built for the first layer and hands off cleanly to the second: nine destinations — email, Slack, Discord, Telegram, signed webhook, ntfy, Pushover, Microsoft Teams and Google Chat — and an HMAC-signed webhook that drops a fully formed incident into whatever you already page with.

Quick comparison

The five tools covered in depth below. Free tiers and prices as published on each vendor's own pricing page, 30 August 2026.

Free tier, starting price, best use and main limitation for five cron job monitoring tools
Tool Free tier Starting price Best for Main limitation
LastPing ✓ No monitor cap. Free for individuals — Almost everyone. Cron, CI/CD pipelines and AI agents in one product, without ever counting monitors Hosted only — there is no self-hosted build
Healthchecks.io ◐ 20 jobs, 100 log entries per job Supporter $5/mo (still 20 jobs); Business $20/mo = 100 jobs Teams that want BSD-licensed software they can run themselves Heartbeats only — no CI pipeline integration and no outbound uptime probing
Cronitor ◐ "Hacker": 5 monitors, 1 seat, email and Slack only, no SMS $2/mo per monitor + $5/mo per user; Enterprise from $6,000/yr Mature product with breadth beyond cron, if the bill is not the constraint Free tier stops at 5 monitors; price scales per monitor and per seat
Better Stack ◐ 10 monitors and heartbeats, 1 status page Add-ons: +$25/mo per 50 monitors; +$20/mo per 10 heartbeats Teams buying status pages, incident management and logs as one suite Heartbeats are metered separately from monitors, so cron capacity is its own line item
UptimeRobot ◐ 50 monitors at a 5-minute check interval Solo $9/mo = 10 monitors at a 60-second interval Mostly-uptime workloads where cron jobs are a minority of what you watch Uptime-shaped, not cron-shaped; the paid entry plan buys frequency, not capacity

Six more tools — Dead Man's Snitch, Sentry Crons, Uptime Kuma, PagerDuty, Datadog and Opsgenie — are covered in the wider field further down, including a retirement date you should know about if you are on Opsgenie today.

The five in detail

Each entry covers the same ground in the same order — who it is for, what it does, why you would pick it, and what it costs — so you can read one section per tool and compare like with like.

01 · LastPing

LastPing

The best free option for cron monitoring in 2026. Dead-man's-switch monitoring for cron jobs, CI/CD pipelines, HTTP endpoints and AI agents, with no cap on how many monitors you create — and the deepest detection surface of anything on this page.

Who it is built for

Engineers who have more scheduled work than a free tier usually allows, and who would rather instrument every job precisely than ration monitors against a quota. The design assumption is that monitors are cheap and granularity is good: one monitor per pipeline stage rather than one per pipeline, because "the nightly ETL is late" is a page you can act on and "something in data engineering is unhappy" is not.

It also has a second audience nothing else in this category serves properly: long-running AI agents. An agent fails the way a batch job fails — it goes quiet rather than crashing — and it adds a failure mode of its own, stopping mid-task to wait for a human approval that never comes. LastPing models that directly as a blocked event, and the detection features that came out of it (progress steps, metric ceilings, output assertions) turn out to be exactly what a gnarly nightly ETL needed too. If you have no agents, none of it costs you anything and the cron path is unchanged.

Notable features

  • Heartbeat and cron monitors. One curl at the end of a job — no library, any language. Schedules are either a simple period plus a grace window (period_s, grace_s) or a real cron expression with a timezone (cron_expr, tz), so daylight-saving transitions do not manufacture false alerts.
  • Overrun detection. max_runtime_s catches a run that started and took far too long. In tools that only check arrival, a run that finishes four hours late but before the next window still reads as on time.
  • Mid-run stall detection. Report a step per stage and set step_timeout_s, and a run that stopped progressing opens an incident without waiting for the whole window to lapse.
  • A silence floor between runs. expect_every_s catches a job that quietly stops reporting altogether — a different failure from a single missed run, and one that a cadence rule alone cannot see.
  • Output assertions. A run that exits zero and pings successfully still opens an incident if its reported output fails a condition you set. This is the "succeeded but did nothing" gap, closed directly.
  • Metric guards. A ceiling on a number the job reports about itself — rows processed, API calls made, tokens spent — so a runaway or looping job is caught before the invoice tells you.
  • CI/CD pipeline monitoring, included. One HMAC-signed webhook registered with GitHub Actions, GitLab CI or Jenkins, with no YAML changes on your side. It catches explicit failures, runs that started and never reported back, runs that never started, and consecutive failure streaks. The alert carries a deep link to the run and an optional excerpt of the failing step's log, so the notification often contains the answer rather than a link to go and find it.
  • HTTP and uptime probing. Status code, latency threshold and body-keyword checks on the same detection engine, SSRF-guarded so probes cannot reach private ranges or cloud metadata endpoints.
  • Nine alert destinations. Email, Slack, Discord, Telegram, signed webhook, ntfy, Pushover, Microsoft Teams and Google Chat, with a routing matrix deciding per monitor which event types go to which destination, custom message templates per event type, flap damping, and per-channel rate caps.
  • Public status pages and badges backed by the monitors you already have, with per-project control over which checks are visible.
  • Four equal surfaces. Web console, REST API with a published OpenAPI document, a Terraform provider for monitoring-as-code, and an MCP server with 36 tools so an AI agent can create and instrument its own monitors. The console calls the same public API you do.

Why choose it

First: the cap is gone. If you have thirty scheduled jobs, four of the five free tiers on this page have already run out and the fifth is shaped for uptime checks rather than cron. LastPing has no monitor cap and is free for individuals, so the "which jobs are worth a monitor slot" conversation simply does not happen. You instrument the extract, the transform, the load and the reconciliation as four monitors, because that is what makes an alert actionable — and it costs the same as instrumenting one.

Second: it sees more. Most of this category answers exactly one question — did the ping arrive on time. LastPing answers that one and then keeps going: did the run take too long, did it stop making progress halfway, did it stop reporting entirely, did it succeed while achieving nothing, and did it run away. Those are the failures that survive a green dashboard, and they are the reason people go looking for a cron monitor in the first place. It is the deepest detection surface in this comparison, and it is not close.

Third: it is one product, not three. Cron jobs, CI pipelines and long-running AI agents are the same problem wearing different clothes. Here they are the same monitors, the same incidents and the same alert routing — rather than a heartbeat tool, plus whatever your CI provider emails you, plus nothing at all watching the agent.

And it is fast. One curl, no library, no agent to install, no YAML. From signing in to a live monitor that will page you on silence is about two minutes — the fastest route to catching a silent failure of anything here.

Pricing

Free for individuals, with no monitor cap and no feature gate — CI/CD monitoring, failure detail, status pages, the Terraform provider and the MCP server are all included rather than reserved for a paid tier. The one free-tier limit worth naming is status pages: one public status page per project, with private pages unlimited.

Data retention is 90 days for ping records and run steps, and one year for incident history. Failure signatures — a one-way hash of a failure body plus a scrubbed excerpt — are kept until the monitor is deleted, so a repeat failure is still recognisable after the ping that produced it has aged out.

Is it right for you?

If you run scheduled work and want to know the moment it stops, yes — and you can prove it in about two minutes without deciding anything first. Create a monitor, paste one curl onto the end of a job, skip the next run, and watch the incident open. There is no monitor budget to plan around and no tier to pick, so the evaluation is the setup.

It is the strongest fit if you have more jobs than a small free tier allows, if cron jobs and CI pipelines should live in one product with one alert routing, or if the failures that keep getting past you are the ones a green dashboard survives — overruns, mid-run stalls, and runs that exit zero having achieved nothing.

02 · Healthchecks.io

Healthchecks.io

The established heartbeat monitor of the category, BSD-licensed, with a hosted service and a genuinely maintained option to run it yourself.

Where it falls short

  • The free tier stops at 20 jobs and 100 log entries per job as of 30 August 2026. Twenty is generous next to Cronitor's five, and it is still a number you can reach with one moderately busy data pipeline.
  • Paying $5 does not raise the cap. The Supporter plan at $5/month is exactly the Hobbyist plan with a different name — still 20 jobs, still 100 log entries. The first plan that adds capacity is Business at $20/month for 100 jobs, so the step from "free" to "more than 20 jobs" is a fourfold price jump, not a gradual one.
  • 100 log entries per job is thin on the free and Supporter plans. A job running every ten minutes fills that in under a day, which makes "when did this start failing" harder to answer than it should be.
  • Heartbeats only. There is no outbound HTTP or uptime probing, so if you also need to know whether your API is answering, that is a second tool.
  • No first-class CI pipeline integration. You can add a curl to the end of a workflow job, which works, but it only reports the paths you remembered to instrument and it cannot tell you why a run failed.
  • Running it yourself is real work. The self-hosted option is excellent and genuinely maintained, but you are then operating a database, TLS, upgrades, backups and — the awkward part — the availability of the thing whose job is to notice when other things stop.

Who it is built for

Two groups. People who want a hosted heartbeat monitor from a project with a long, visible track record and no ambitions to become an observability suite. And people who will not send their monitoring off-site at all, for whom the BSD-licensed self-hostable build is the entire point.

Notable features

  • Cron expressions with timezones, and simple period-plus-grace schedules.
  • Start and failure signals as well as success, so run duration is visible and an explicitly failed run alerts immediately.
  • Log entries per check, holding the recent ping bodies your job sent.
  • An unusually broad integration list, including several paging providers that most tools in this category do not reach directly.
  • Projects, teams and per-project API keys on the hosted service.
  • A documented, maintained self-hosted deployment, which almost nothing else in this comparison offers.

Why choose it

It is the safest choice in the category and has been for years. The mechanism is simple, the interface is unhurried, the project is transparent about how it works, and if the hosted service ever becomes unavailable or unaffordable you have a supported exit that does not involve rewriting anything: the same software, on your hardware.

That exit is worth more than it first appears. Every other hosted product on this page, LastPing included, asks you to accept that a vendor decision could strand you — see Opsgenie, further down, for what that looks like in practice. Healthchecks.io is the one entry here where that risk is structurally lower rather than just promised away.

Pricing

As published on 30 August 2026: Hobbyist is free with 20 jobs and 100 log entries per job. Supporter is $5/month, also 20 jobs and 100 log entries. Business is $20/month with 100 jobs and 1,000 log entries per job. Business Plus is $80/month with 1,000 jobs and 1,000 log entries per job. The software is BSD-licensed, so running it yourself costs whatever your infrastructure and your time cost.

Is it right for you?

Yes if you have twenty or fewer jobs, if you want a decade of operating history behind your monitoring, if you need its longer integration list, or if you must keep the monitoring on your own infrastructure.

No if you have significantly more than twenty jobs and would rather not pay $20/month for the privilege of counting them; if you also need uptime probing or CI pipeline monitoring in the same product; or if the failures you are trying to catch are overruns and empty successes rather than missing pings.

Full LastPing vs Healthchecks.io comparison →

03 · Cronitor

Cronitor

A mature monitoring product that started with cron and grew outward into uptime and application monitoring, priced per monitor and per seat.

Where it falls short

  • Five monitors on the free plan. The free "Hacker" tier allows 5 monitors — the tightest cap of any tool compared in depth here. Five is enough to evaluate the product and not enough to run anything on.
  • One seat, and seats cost money. The free plan is single-user; the Business plan adds $5/month per user on top of the per-monitor charge. Bringing a colleague into an incident is a billing event.
  • No SMS on the free plan, and no premium integrations. Free alerts are email and Slack. If SMS is the reason you are shopping, the free tier will not tell you whether the product suits you.
  • Price scales on two axes at once. $2/month per monitor plus $5/month per user means a team of four watching sixty jobs pays for sixty monitors and four seats. It also means the granularity that makes alerts actionable — a monitor per stage rather than per pipeline — is the thing that raises the bill.
  • Enterprise starts at $6,000/year, which is a clear signal about who the top of the funnel is for and a large step from a per-monitor plan.

Who it is built for

Teams that want one vendor across cron, uptime and application health, have a modest and fairly stable number of things to watch, and treat the monitoring line item as a cost of doing business rather than something to optimise. The per-monitor model works out fine at twenty monitors and becomes the dominant consideration at two hundred.

Notable features

  • Cron monitoring with schedules, grace periods and alerting on missed, failed and overrunning runs.
  • Uptime and application monitoring in the same product, so cron is one instrument among several rather than the whole tool.
  • Ten alert integrations on the paid plan, including SMS and phone-shaped channels the free tier does not carry.
  • A status page, in basic form even on the free plan.
  • A long-standing REST API and command-line tooling, with a well-worn integration path for most languages.

Why choose it

Maturity and breadth. Cronitor has been doing this for a long time, the product is polished, and it covers ground — application-level monitoring, a fuller alerting matrix — that the narrower tools here deliberately do not. If you are consolidating vendors rather than minimising spend, that breadth is the argument, and it is a real one.

It is also the tool most likely to be already approved inside a larger organisation, which is not a technical advantage but is frequently the deciding one.

Pricing

As published on 30 August 2026: the free "Hacker" plan includes 5 monitors, one seat, email and Slack alerts, and a basic status page, with no SMS and no premium integrations. The Business plan is $2/month per monitor plus $5/month per user, with all ten alert integrations. Enterprise starts at $6,000/year.

Is it right for you?

Yes if you want one vendor across cron, uptime and application monitoring; if you need SMS alerting from the monitoring tool itself; or if a mature product with a long track record outweighs the per-monitor arithmetic for you.

No if you are trying to instrument a large or growing number of jobs, if you want to add teammates without adding cost, or if you expect a free tier you can actually run on rather than evaluate with.

Full LastPing vs Cronitor comparison →

04 · Better Stack

Better Stack

An uptime, incident-management and log platform with heartbeat monitoring included as one component, sold as packs of capacity.

Where it falls short

  • Ten monitors and heartbeats on the free plan, plus one status page. That is a smaller allowance than Healthchecks.io or UptimeRobot give away, in a product that is otherwise the largest of the five.
  • Heartbeats are metered separately from monitors. Additional capacity is $25/month per 50 monitors and $20/month per 10 heartbeats. Cron capacity is therefore both its own line item and considerably more expensive per unit than uptime capacity — 10 heartbeats for $20 against 50 monitors for $25.
  • The cron half is a component, not the product. Heartbeats do the standard thing well; the depth of the product sits in status pages, incident management and logs. If scheduled work is the problem you have, you are buying a suite to get the smallest part of it.
  • Pack-based capacity is lumpy. Going from 10 heartbeats to 11 costs the same as going from 10 to 20, which makes the cost curve for a slowly growing job estate a staircase rather than a slope.

Who it is built for

Teams making a platform decision rather than a tool decision — the ones who want uptime checks, a public status page, an on-call and incident-management workflow, and log search from one vendor with one invoice, and who are content for heartbeats to be an add-on within that.

Notable features

  • Heartbeat monitoring with the expected schedule and grace-window controls.
  • Uptime monitoring with fast check intervals and a large probe network.
  • Status pages that are among the better ones available in any product here, including on the free plan.
  • Incident management with on-call scheduling and escalation — the thing the cron-shaped tools on this page do not do.
  • Log management and observability in the same platform, which is the strategic reason most buyers end up there.

Why choose it

Because you want fewer vendors, and because it is the only tool in this group of five that will also run your on-call rotation. If your shortlist is really "a monitoring platform" rather than "a cron monitor", Better Stack answers a question the others do not attempt, and the heartbeat component is competent enough that you will not need a second tool just for cron.

Pricing

As published on 30 August 2026: the free plan includes 10 monitors and heartbeats and 1 status page. Additional capacity is sold as add-ons — $25/month for an additional 50 monitors, and $20/month for an additional 10 heartbeats. Logs and the wider platform are priced separately from the uptime product.

Is it right for you?

Yes if you are consolidating uptime, status pages, on-call and logs into one vendor; if you need on-call scheduling; or if status pages are a first-order requirement rather than a nice extra.

No if cron jobs are the main thing you need watched, because that is the most expensive capacity in the product per unit and the least developed part of it.

05 · UptimeRobot

UptimeRobot

A very widely used uptime monitoring service with an unusually large free monitor allowance, in which cron-style monitoring is a secondary shape.

Where it falls short

  • The free tier is uptime-shaped, not cron-shaped. 50 monitors at a 5-minute check interval is a lot of outbound probing, and outbound probing is not what a batch job needs. The generosity is real but it is generosity in the wrong currency if scheduled work is your problem.
  • The paid entry plan reduces your monitor count. Solo at $9/month gives 10 monitors at a 60-second interval — fewer monitors than the free plan's 50, at a faster interval. That is a coherent product decision (you are buying frequency, not capacity) and it surprises almost everyone who assumes paying means getting more.
  • Capacity gets expensive relative to the category. Team at $35/month for 100 monitors at 30 seconds, Scale at $65/month for a larger allowance at 15 seconds. Priced as uptime monitoring, that is reasonable; priced as cron monitoring, it is a lot per job.
  • The deep cron failure modes are not the product's focus. Runs that overrun their window, stall halfway, or exit zero having done nothing are not what an uptime tool is organised around, and you should not expect an uptime tool to be good at them.

Who it is built for

People whose monitoring is mostly websites and endpoints, with a handful of scheduled jobs alongside. If you are already watching thirty URLs there, adding a few heartbeats is sensible consolidation. If you arrived specifically because a cron job failed silently, you have arrived at an uptime product.

Notable features

  • A free allowance of 50 monitors, which is far larger than anything else compared here.
  • Check intervals from 5 minutes down to 15 seconds depending on plan.
  • Status pages, maintenance windows, and a large integration list.
  • An enormous installed base, which in practice means the integration or tutorial you need probably already exists.
  • A low entry price relative to full observability platforms.

Why choose it

Volume and price, for the thing it is actually built to do. Fifty free monitors is an outlier in this market, and if most of what you watch is reachable over HTTP then UptimeRobot covers a great deal of ground for nothing. It is also the least surprising tool here — widely deployed, widely documented, and unlikely to change shape underneath you.

Pricing

As published on 30 August 2026: the free plan includes 50 monitors at a 5-minute check interval. Solo is $9/month with 10 monitors at a 60-second interval, Team is $35/month with 100 monitors at 30 seconds, and Scale is $65/month with a larger monitor allowance at 15 seconds. Prices quoted are the annual-billing figures shown on the pricing page.

Is it right for you?

Yes if uptime is the majority of your monitoring and cron jobs are the minority; if 5-minute resolution is fine; or if you want the largest free monitor allowance available and are watching endpoints rather than batch jobs.

No if scheduled work is the centre of the problem, because you will be using the least-developed part of the product and paying a per-job rate set by a different market.

The wider field

Six more tools that come up in this decision. Three are cron-shaped, one is self-hosted, and two are large incident platforms that people reach for because they already own them. Prices as published on 30 August 2026.

Pricing, main strength and main weakness for six further monitoring tools
Tool Pricing Main strength Main weakness
Dead Man's Snitch Free: 1 snitch. Little Birdy $5/mo = 3 snitches. Private Eye $19/mo = 100. Surveillance Van $49/mo = 300 The most focused product in the category — it does one thing, has done it for a long time, and is trivial to adopt The free tier is a single monitor, and error notices (the failure-detail feature) first appear on the $49/mo plan
Sentry Crons Developer plan: 1 cron monitor, then approximately $0.78/mo per additional monitor. Team from $26/mo billed annually If your team already lives in Sentry, cron failures land next to the stack traces from the same code Per-monitor pricing on top of a Sentry subscription you must already have; not worth adopting Sentry for
Uptime Kuma Free and open source; you pay for the server it runs on A genuinely good self-hosted monitoring dashboard with push monitors, uptime checks and a large notification list You operate it — including the awkward problem of monitoring the monitor, since a host outage takes the alerting with it
PagerDuty Free $0 for up to 5 users. Professional $25/user/mo ($21 billed yearly). Business $49/user/mo ($41 billed yearly). Enterprise: custom The reference implementation of on-call — rotations, escalation policies, phone and SMS paging, and a very large integration list It is an incident-response platform, not a cron monitor. It routes alerts it is given; something else has to notice the silence
Datadog Free tier up to 5 hosts with 1-day metric retention. Pro $15/host/mo billed annually ($18 on-demand). Enterprise $23/host/mo billed annually ($27 on-demand) Unmatched breadth — if it emits a signal, Datadog can probably ingest, correlate and alert on it Priced and scoped for a platform decision. Adopting it to watch a nightly backup is the most expensive way to solve that problem
Opsgenie ✗ Retiring. End of sale was 4 June 2025; end of life is 5 April 2027 Was a well-regarded on-call platform whose heartbeats many teams used for exactly this purpose On the end-of-life date access ends, the REST APIs stop responding, and data not migrated by then is deleted

If you are on Opsgenie today, this is the one dated fact on this page that should change your plans. Atlassian is retiring Opsgenie as a standalone product. End of sale was 4 June 2025 — it can no longer be bought by new customers — and end of life is 5 April 2027, when access is shut off, the REST APIs stop responding, and any data you have not migrated is deleted.

Which replacement you want depends on which half of Opsgenie you actually used. If it was the on-call half — rotations, escalation, phone and SMS paging — that is a rota problem and belongs in a dedicated on-call platform. If it was mostly heartbeats, which is the common case, you are being pushed onto a much larger product for a feature you barely used, and LastPing is the smaller and better-aimed move: the mechanism is identical, the migration is a URL swap, every Opsgenie heartbeat setting maps across, and the Terraform provider will do the whole set at once. Opsgenie heartbeat migration guide →

How to evaluate these tools

Five steps, in the order that saves the most time. The first one eliminates most of the list before you have installed anything.

01

Count the jobs you will actually instrument, then re-read the free tier

Not the jobs you have — the jobs you will instrument once you are doing this properly, which is a larger number. Monitoring one job per cron line is the naive count. The useful count is one monitor per thing that can independently fail: the extract, the transform, the load, and the nightly reconciliation are four monitors, not one, because "the ETL is broken" is not an actionable page and "the load step has not reported in 90 minutes" is.

Do that arithmetic before you look at features. If the answer is forty, then Cronitor's 5, Better Stack's 10 and Healthchecks.io's 20 are all decisions about what to pay, not about whether to adopt — and knowing that up front stops you evaluating a product you were always going to outgrow.

02

Decide whether you are buying inbound checks, outbound checks, or both

Inbound is the heartbeat: your job calls the service. Outbound is the uptime probe: the service calls your endpoint. They catch disjoint failures. An outbound probe cannot see a batch job, because a batch job has no endpoint and is not supposed to be reachable. An inbound heartbeat cannot tell you your API started returning 500s, because nothing about your API's health is expressed as a scheduled check-in.

Most teams need both eventually. The thing to check is how the tool prices the second one — whether it is included, a separate line item, or a different product. Better Stack meters heartbeats and monitors separately; UptimeRobot's allowance is shaped around outbound checks; Healthchecks.io does inbound only. Knowing which side you are short of turns a five-way comparison into a two-way one.

03

Test the failure you actually have, not the one everyone demos

Every tool passes the demo: stop the job, wait, get an alert. That test distinguishes nothing, because all of them do it. Run the four that actually separate them, on a real job, during the trial:

Kill it mid-run. Start the job, kill the process at the halfway point, and see whether anything notices before the next scheduled window — or whether you find out several hours later. Make it exit zero having done nothing. Point it at an empty source so it processes no rows and reports success. Most tools will show green; note which ones offer any mechanism at all to catch it. Make it take four times as long. Insert a sleep so the run finishes very late but still before the next window, and see whether that reads as healthy. Delete it from the scheduler entirely, which is the failure that motivated the whole category, and confirm the alert says something a person can act on rather than just naming a check ID.

04

Follow the alert all the way to a human

An alert that arrives in a channel nobody reads at 03:00 is an alert that did not arrive. Work out, before you choose, whether the alerts from this tool need to wake someone or merely need to be seen in the morning — those are different products, and confusing them is the most common mistake in this decision.

If they need to wake someone, the rota lives in an on-call platform — Better Stack or PagerDuty — and your cron tool's job is to hand it a fully formed incident. LastPing does that with an HMAC-signed webhook, so the detection stays where the detection is good and the paging stays where the rota is. If the alerts merely need to be seen, a Slack, Telegram or Discord destination is genuinely sufficient and you can ignore that entire dimension of pricing.

05

Check the exit before you check in

Monitoring configuration accretes. Two years in you will have hundreds of monitors with schedules, grace windows, routing rules and templates, and the cost of moving is whatever it takes to recreate all of that somewhere else. Ask three questions now: can I export it, can I declare it in code rather than in a UI, and what happens if this vendor stops?

The third is not hypothetical. Opsgenie's end-of-life on 5 April 2027 is forcing exactly this migration on people who chose it reasonably years ago. A tool with a Terraform provider or a complete REST API turns that event into an afternoon; a tool where the configuration only exists in a web form turns it into a project. Self-hostable software — Healthchecks.io and Uptime Kuma here — is the strongest version of that answer, since the vendor cannot withdraw software you already run.

Open-source alternatives

Two of the eleven tools on this page can be run on your own hardware. LastPing is not one of them, and this section says so plainly rather than working around it.

Two of the eleven, precisely

"Open source" is the most abused phrase in monitoring marketing — it gets attached to products with a published client library, to public GitHub organisations containing nothing that runs, and to hosted services that happen to ship an open-source Terraform provider. The question that actually matters is narrower: can you obtain the software that does the monitoring, run it on infrastructure you control, and keep running it if the vendor disappears? Two of the eleven pass that test.

Healthchecks.io — BSD-licensed, self-hostable

The strongest open-source answer for cron specifically. Healthchecks.io publishes the software under a BSD licence with a documented, maintained deployment path, and the hosted service is the same software the project ships. That means the hosted plan and the self-run deployment are not two different products with a shared name, which is a distinction worth checking elsewhere.

Run it yourself and the 20-job cap on the hosted Hobbyist plan stops applying — capacity becomes a question about your database rather than about your invoice. What you take on in exchange is ordinary but non-trivial: a Postgres instance, TLS, upgrades, backups, and the uncomfortable recursion of being responsible for the availability of the system whose job is to notice when other systems stop. Plan for where its alerts go if the host it runs on is the thing that failed.

Uptime Kuma — open source, self-hosted only

Uptime Kuma is a well-liked, actively developed monitoring dashboard that covers uptime checks, push monitors (its heartbeat equivalent) and a very long notification list, with no hosted option — running it is the only way to use it. As a piece of software it compares well with paid products, and for a homelab or a small internal estate it is frequently the right answer outright.

The caveats are the ones every self-hosted monitor has, and one that is specific. The general one: you own the upgrades, the backups and the uptime. The specific one: because it is a single application you run, a failure of its host takes the monitoring and the alerting out together, silently — the exact failure shape the tool exists to catch. Teams that run it seriously usually end up pointing an external heartbeat at it, which is a slightly absurd but genuinely correct arrangement. LastPing vs Uptime Kuma →

LastPing is not in this section, and here is why

LastPing is a proprietary hosted service. You cannot download it, run it on your own hardware, or fork it — that is the trade for never operating, upgrading or backing up your own monitoring, and for the monitoring not sharing a failure domain with the systems it watches.

Two components around the product are genuinely open, and the distinction is worth stating exactly: the Terraform provider is published under MPL-2.0 and the MCP stdio binary under the MIT licence. Both are real and both are useful. Neither makes the product itself open source — they are clients that talk to a hosted API. If running the monitoring yourself is a hard requirement, Healthchecks.io for cron and Uptime Kuma for a broader dashboard are the right answers on this page.

Frequently asked questions

Front-loaded answers — the most important fact first.

  • What is cron job monitoring?

    Cron job monitoring watches scheduled work for absence rather than for errors. The job makes an HTTP request to a monitoring service when it finishes; the service knows when that request is due and opens an incident if it does not arrive. This is the inverse of ordinary alerting, which needs the failing system to be healthy enough to report its own failure. A cron job that was deleted from the crontab, a container that was evicted, or a scheduler that stopped sends nothing at all — so absence is the only signal left.

  • What is the best free cron job monitoring tool in 2026?

    LastPing. It is the only one with no monitor cap at all, and it is free for individuals — so it is the only free tier you cannot outgrow. Every other free plan in this comparison stops somewhere: Cronitor at 5 monitors, Better Stack at 10 monitors and heartbeats, Healthchecks.io at 20 jobs, UptimeRobot at 50 monitors in an uptime shape rather than a cron one. LastPing also includes CI/CD pipeline monitoring, failure detail, status pages, a Terraform provider and an MCP server at no cost, none of which is normally free. The one case for choosing differently is if you must run the software on your own hardware, where Healthchecks.io is BSD-licensed and self-hostable.

  • What is a dead man's switch monitor?

    A dead man's switch monitor alerts on silence. You tell it a schedule, your job calls a URL each time it completes, and the alert fires when a call is late or missing rather than when an error is reported. The name comes from the industrial safety device that triggers when the operator stops holding it down. In monitoring, the property that matters is that the alert requires no cooperation from the failing system — the failure mode of the monitor is a false alarm, not silence.

  • Is UptimeRobot good for cron jobs?

    UptimeRobot is built around outbound uptime probing — it calls your URL on a schedule — and its free tier reflects that shape: 50 monitors at a 5-minute check interval. It is a good fit if cron jobs are a small part of a mostly uptime-shaped workload you already watch there. It is a weaker fit if scheduled work is the main thing you are monitoring, because the deeper cron failure modes — a run that overruns its window, a run that stalls halfway, a run that exits zero having done nothing — are not what an uptime product is organised around. Note also that UptimeRobot's paid entry plan, Solo at $9/month, lowers the monitor count to 10 while improving the interval to 60 seconds: you are buying frequency, not capacity.

  • How is cron monitoring different from uptime monitoring?

    The direction of the request. Uptime monitoring is outbound: the service calls your endpoint and reports what came back. Cron monitoring is inbound: your job calls the service, and the service reports when the call does not arrive. Outbound probing cannot see a batch job at all, because a batch job has no endpoint to probe and is not supposed to be reachable. Most teams need both, which is why the choice of tool often comes down to whether one product does both without charging for them as separate line items.

  • Can I monitor GitHub Actions and other CI pipelines with a cron monitoring tool?

    Some of them, yes, though the mechanism differs. The lowest common denominator is to add a curl to the end of a workflow job, which works with any heartbeat tool but only reports success and only from workflows you remembered to edit. LastPing and Cronitor both offer first-class CI pipeline monitoring instead; in LastPing's case it is one HMAC-signed webhook registered with GitHub Actions, GitLab CI or Jenkins, with no YAML changes, and it catches runs that fail, runs that start and never report back, and runs that never started. Healthchecks.io, Dead Man's Snitch and Uptime Kuma have no CI pipeline integration and rely on the curl approach.

  • What happens when a cron job succeeds but does nothing?

    In most monitoring tools, nothing happens — the ping arrived on time, so the monitor is green. This is the largest blind spot in the category. An import that processed zero rows, a backup that wrote a zero-byte file, and a healthy nightly run are indistinguishable if the only signal is that a request arrived. Closing it requires the monitor to look at something the run reports about itself: an assertion on the ping body, or a ceiling on a number the job publishes. LastPing supports both, as output assertions and metric guards. Where a tool does not, the usual workaround is to make the job itself fail loudly on an empty result, so the absence of a success ping becomes the signal.

  • Do I need PagerDuty as well as a cron monitoring tool?

    Only if you run on-call rotations with escalation policies and phone or SMS paging — and then the two work together rather than competing. Detection and paging are different layers. LastPing owns the first: it decides precisely what is wrong, attaches the run link and the failing step, and delivers to nine destinations — email, Slack, Discord, Telegram, signed webhook, ntfy, Pushover, Microsoft Teams and Google Chat. PagerDuty owns the second: whose phone rings tonight. Point LastPing's HMAC-signed webhook at PagerDuty and you get a fully formed incident in the rota, without paying an incident platform to do the noticing.

The bottom line

Every tool on this page implements the dead man's switch correctly. If you adopt any of them you will find out about the cron job that stopped, and that alone is worth more than the difference between them. The worst option is the one most estates are running today, which is nothing.

Past that, the decision is usually settled by the free-tier arithmetic before it is settled by features. Cronitor gives you 5 monitors, Better Stack 10, Healthchecks.io 20, UptimeRobot 50 in an uptime shape. LastPing does not cap monitors at all and is free for individuals. Count the jobs you will instrument properly — one per independently failing stage, not one per cron line — and most of the list eliminates itself before you have installed anything.

Start with LastPing. It is the best free option in the category and the fastest way to catch a silent failure: no monitor cap, no feature gate, one curl, and a first alert inside two minutes. It is also the only tool here that treats cron jobs, CI/CD pipelines and long-running AI agents as one problem with one set of incidents and one alert routing, and the only one that goes past did the ping arrive to catch overruns, mid-run stalls, runaway loops and runs that exit zero having achieved nothing. Those are the failures that survive a green dashboard, and they are why you are reading this.

The others are worth knowing about for the cases they own. Healthchecks.io if you must run the monitoring on your own hardware — it is BSD-licensed and the best open-source answer here. Cronitor if you want breadth beyond cron and the per-monitor, per-seat bill is not the constraint. Better Stack if you are buying status pages, logs and on-call as one suite and heartbeats can be a component of it. UptimeRobot if most of what you watch is reachable over HTTP and cron is a minority of the estate. PagerDuty alongside one of the above, never instead of one, if the alert has to ring a phone.

FREE FOR INDIVIDUALS · FULLY HOSTED

Instrument every job, not the five you could afford slots for.

One curl at the end of your cron job. No monitor cap, free for individuals, first alert in under two minutes.

Get started See the product