Why Monitoring-Only Cron Tools Are a Trap (You Still Have to SSH In)

Cron monitoring tools such as Cronitor, Healthchecks.io, Dead Man’s Snitch, and Sentry Crons work the same way: your job pings in on success, and if it doesn’t, you get alerted. That’s useful, but it covers only half the problem, and the half it leaves is the costlier one.

Monitoring shortens detection, not the fix

Mean time to resolution breaks into two intervals: time-to-detect (the job breaks, how long until someone knows) and time-to-fix (someone knows, how long until it’s actually resolved). Heartbeat monitoring is purely a time-to-detect tool. It takes an interval that might have been “whenever someone notices the downstream report is empty” and turns it into “however long your grace period is.” That’s a real improvement: minutes instead of hours or days.

But time-to-fix doesn’t move. Once you’re alerted, the actual remediation is identical to what it would have been if you’d found out by accident: you SSH into the box, you read logs, you find whatever broke (a bad schedule, a script that started failing, a dependency that moved), and you fix it by hand. The monitoring tool’s job ends at the alert. It isn’t connected to anything it could change, so it can’t help with what happens next.

Why monitors can’t fix anything

A heartbeat monitor’s only connection to your infrastructure is an inbound HTTP ping. It has no credentials to your box, can’t see your crontab, and can’t alter either. That’s by design: a tool that never touches production can’t break production, and many teams choose to separate the thing that watches from the thing that can change state because it limits blast radius and keeps the monitor simple.

The problem comes from expecting a monitoring-only tool to do more than watch, and being surprised at every incident when it doesn’t.

What the gap costs in practice

When a nightly job fails, the sequence looks like this:

1. Grace period elapses, alert fires. (Monitoring tool’s job is done here.)
2. You see the alert, maybe immediately, maybe when you wake up.
3. You open a terminal, SSH into the machine that runs the job.
4. You find the crontab entry, or the script it calls, and figure out what changed.
5. You fix it by hand on that one box: edit the schedule, patch the script, or redeploy.
6. If the fix needs to go everywhere and you manage more than one machine, you repeat steps 3 to 5 on each.

Steps 3 through 6 are manual and unmonitored, and they take most of the time. Say a monitoring tool cuts detection from six hours to six minutes but leaves a 40-minute manual fix: it hasn’t touched the larger number.

When monitoring-only is the right choice

The strongest case for staying monitoring-only is architecture. A tool with no write access to production has a smaller failure surface, is easier to reason about, and can’t turn a monitoring incident into an outage. If your team has strong SSH habits, a fast on-call rotation, and jobs simple enough that fixes are quick, the manual steps above may be fine. Adding remote write access without a real gap in remediation time would solve a problem you don’t have.

Closing the gap makes sense where that manual sequence is the bottleneck: multiple machines, schedules that drift or get misconfigured often enough to cost you, or an on-call rotation where SSHing into an unfamiliar box at 3am is itself the risky part.

Closing the gap with a pairing step

Monitoring and management have historically been separate products from different companies with different threat models. norc closes the gap: you pair machines (local or remote) once, and from then on you can view, edit, and deploy crontab entries from the same place you see run history and failures. The pairing step is the trust boundary.

Monitoring-only tools are a different tradeoff. Choose one on purpose, not because it came up first in a search.

Example: a backup job with a changed auth header

Say a nightly backup job starts failing because a downstream API changed its auth header. Under a monitoring-only setup: the heartbeat doesn’t arrive, you get paged, you SSH in, crontab -l to confirm the schedule is actually what you think it is, tail the job’s log to find the auth error, patch the script or rotate the credential, and manually verify the next run. If the same job runs on three other machines with the same misconfiguration, you do all of that three more times.

Under a control-plane setup, the failure and the run history that led to it are in the same view you’d already be looking at, with no separate SSH session just to establish “is the schedule even what I think it is.” The fix (a credential update, a schedule change, a redeploy of the corrected script) happens from there, and if the same job exists on other paired machines, you’re operating on the fleet instead of repeating the loop per box. The diagnosis step stays, since someone still has to figure out the auth header changed, but the box-by-box mechanical overhead goes away.

Cost with more machines

If every fix is manual and per-box, the cost grows with the number of machines. One SSH session on a single server is no big deal. Running the same job across many machines makes the manual loop the main cost of an incident, and a faster alert doesn’t change that.

If you want the deeper mechanics of what remote management actually looks like, see cron across multiple servers, or the full tool comparison for how the two categories stack up feature by feature.

FAQ

Doesn’t remote write access make things less safe? It’s a real tradeoff. The mitigation is that the connection is explicit (you pair a machine deliberately) and scoped to schedule management, not arbitrary remote execution. It’s still a fair question to ask of any tool that can change a box, and worth weighing against your own risk tolerance.

Is heartbeat monitoring useless, then? No. It’s the right tool for detection, and for teams that only need detection, a dedicated monitor with no write access is the safer choice because it can’t touch prod.

What’s actually driving MTTR up if not detection speed? In most cron incidents, it’s the manual SSH-diagnose-fix loop, not the time to notice. Detection tools rarely move that number because they were never connected to it.

Can I use a monitoring tool and a management tool together? Yes, and some teams do: a lightweight heartbeat pinger for alerting plus a separate tool for the fix. The tradeoff is running two vendor relationships instead of one for adjacent halves of the same workflow.