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

Every cron monitoring tool on the market — Cronitor, Healthchecks.io, Dead Man’s Snitch, Sentry Crons, all of them — solves the same problem the same way: your job pings in on success, or it doesn’t, and if it doesn’t, you get alerted. That’s a real, useful thing to build. It’s also, mechanically, only half the problem, and the half it doesn’t solve is the expensive one.

MTTR has two halves, and monitoring only fixes one

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 genuine 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 has no way to participate in what happens next, because it was never connected to anything that could change.

The mechanical reason: no write path

This isn’t a criticism of any specific vendor — it’s true by design. A heartbeat monitor’s only connection to your infrastructure is an inbound HTTP ping. It doesn’t have credentials to your box, it doesn’t see your crontab, and it has no mechanism to alter either. That’s not a missing feature; for a pure monitoring product, it’s the point. A tool that never touches production cannot break production. That’s a legitimate, defensible design stance, and plenty of teams choose it deliberately — separating “the thing that watches” from “the thing that can change state” reduces blast radius and keeps the monitor simple and trustworthy.

The trap isn’t using a monitoring-only tool. The trap is expecting it to do more than watch, and then being surprised every single incident when it doesn’t.

What the gap costs in practice

Picture the actual sequence when a nightly job fails:

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 — edit the schedule, patch the script, redeploy — by hand, on that one box.
6. If you manage more than one machine, you repeat step 3–5 per machine if the fix needs to go everywhere.

Steps 3 through 6 are unmonitored, unautomated, and entirely manual, and they’re also where almost all the actual time goes. A monitoring tool that shaves your detection time from six hours to six minutes but leaves a 40-minute manual fix on the other end hasn’t touched the larger number.

The counterargument, taken seriously

The strongest case for staying monitoring-only isn’t inertia, it’s architecture: separation of concerns is a real principle, not an excuse. A tool with no write access to production has a much smaller failure surface, is easier to reason about, and can’t be the thing that turns a monitoring incident into an actual outage. If your team already has strong SSH-based operational habits, a fast on-call rotation, and jobs simple enough that fixes are quick once someone’s on the box, the manual step-3-through-6 sequence above might genuinely be fine for you. Bolting on remote write access for its own sake, without a real gap in your remediation time, would be solving a problem you don’t have.

The case for closing the gap is for teams where that manual sequence is the actual bottleneck: multiple machines, schedules that drift or get misconfigured often enough to be a recurring cost, or an on-call rotation where “SSH into a box I don’t know well at 3am” is itself the risky part.

Closing the gap without giving up the boundary

The reason this gap exists isn’t laziness on any vendor’s part — it’s that monitoring and management have historically been different products built by different companies with different threat models. norc is built to close it directly: 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 write path monitoring tools deliberately don’t have is the whole point — with the pairing step itself acting as the trust boundary, rather than skipping one.

That doesn’t make monitoring-only tools wrong. It makes them a different tradeoff, worth choosing deliberately rather than by default because it’s what came up first in a search.

A concrete example

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 — 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 doesn’t disappear — someone still has to figure out the auth header changed — but the box-by-box mechanical overhead does.

Why this matters more as fleets grow

The gap between detection and remediation scales linearly with the number of machines you manage if every fix is manual and per-box. A single-server setup can absorb that cost without much friction — one SSH session isn’t a big deal. Once you’re running the same job pattern across five, ten, or fifty machines, the manual loop becomes the dominant cost of any incident, and a monitoring tool’s faster alert stops moving the number that actually matters to your team’s time.

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 — but it’s 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 correct tool for the detection half of the problem, and for teams that only need detection, a dedicated monitor with no write access is arguably the safer choice specifically 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.