# Monitoring Cron Jobs & Backups: When Silent Background Processes Fail > Why failed backups and cron jobs so often go unnoticed, and how a dead man's switch catches the silent failure. With a setup walkthrough. Source: https://uptimeify.io/blog/monitoring-cron-jobs-and-backups The most dangerous failure is the one no one notices. A website that goes offline screams: visitors complain, monitoring fires, someone reacts. A backup that hasn't run in three weeks stays silent. There's no error message, no red signal, no phone call. The failure only becomes visible when you urgently need the backup, and discover it doesn't exist. **Cron jobs and backups are therefore monitored differently than a website**: not by waiting for an error signal, but by watching for an expected sign of life. This article explains why silent processes slip through the net, how a dead man's switch catches them, and how you set it up in minutes. - **Silent background processes throw no error when they fail.** A backup that doesn't start is an absence, not an alert. - **Classic monitoring waits for a signal that's missing precisely then**, which is why it overlooks exactly these failures. - **A dead man's switch inverts the logic:** the job checks in; if the check-in is missing, an alert fires. - **The setup is minimal:** one extra line in the script that pings a unique URL after a successful run. - **For agencies:** an unnoticed backup failure is a silent liability. A heartbeat makes it visible. ## Why silent processes slip through the net Ordinary website monitoring works on a simple principle: you ask "is the site up?" regularly and wait for the answer. If no answer or a faulty one comes back, it's clear something is broken. That model is strong, but it assumes there's something to ask in the first place. That's exactly what's missing with background processes. A cron job, a nightly backup, a data import, a cache warmer, none of these runs at an address you could query. They run out of sight, driven by a schedule, and normally report to no one. And here's the catch: when such a process fails, in most cases no event arises that you could observe. A backup script that stops running because of a changed database password throws its error, at most, into a log no one reads. A cron job stopped by a full disk leaves no trace in view. The failure is an **absence**, and absence can't be detected by classic monitoring, because there's nothing there to react to. That's why these failures often stay unnoticed for weeks. Not because they're rare, but because they're quiet. And quiet failures are the most expensive, because you learn of them precisely when it's too late. Classic monitoring detects a failure by a signal, but a failed cron job or an un-started backup produces no signal, it produces an absence. Absence is invisible until you need the result. ## The dead man's switch: monitoring inverted The solution to a problem of absence is to make the absence itself the alarm. That's exactly what a dead man's switch does, a concept named after those safety switches that trigger the moment the operator lets go. Applied to monitoring: it isn't the error signal that fires the alert, but the failure of the success signal to arrive. The mechanics are elegantly simple. The monitored job is given the task of briefly checking in after every successful run, sending an "I worked" to a monitoring endpoint. That sign of life is called a heartbeat. The monitoring, in turn, knows the rhythm this heartbeat should follow: every 24 hours for the nightly backup, every five minutes for the frequent cron job, once a week for the weekly report. As long as the heartbeats arrive on time, all stays quiet. If one is missing, because the job crashed, never started, or hung midway, the monitoring waits for the signal in vain and raises the alarm. The decisive difference from the classic model: here, **silence becomes the trigger**. You no longer have to be able to see the error; it's enough that the expected success signal is missing. That makes visible exactly the kind of failure that was invisible before, the silent, traceless, expensive one. A dead man's switch makes the absence of a success signal the alarm. The job sends a heartbeat after each success; if the expected heartbeat is missing, an alert fires. The silence itself becomes visible. ## The setup: a cron job in minutes The strength of this approach is how little it demands. To monitor a cron job you need no new infrastructure and no library: just a single extra line at the end of your script. The process has three steps. **Step 1: Create a heartbeat monitor.** In the monitoring you create a heartbeat check and set the expected interval, how often the job should check in, plus a tolerance for normal runtime variation. For a nightly backup, say: expected heartbeat every 24 hours, with a few hours' grace. The monitor gives you back a unique ping URL. **Step 2: Add the ping to the script.** At the end of your cron job or backup script, after the successful part, you add a short call to that URL. With `curl` it's one line: ```bash # ... your backup or cron job runs here ... # After a successful run: send the heartbeat curl -fsS --retry 3 https://uptimeify.io/heartbeat/ > /dev/null ``` Placement matters: the ping sits **after** the actual work step, so it only fires if that step ran through. If the script aborts earlier, the ping is never reached, and that's exactly what you want, because then the heartbeat is missing and the alert kicks in. **Step 3: Wire up the alerting.** Finally you attach the heartbeat monitor to the same alerting as your other checks. If a sign of life is missing, the alert runs over the channels you already use, at Uptimeify, over the same confirmed, EU-hosted notification as for website or server monitors. That's it. From now on you know the same day a backup fails, not at the moment you try to restore it. The setup is three-step and minimal: create a heartbeat monitor with an expected interval, add a ping line to the end of the script, attach it to existing alerting. The ping sits after the work step so only real success counts. ## What you can monitor: beyond backups Backups are the most obvious example, but the principle reaches much further. Anywhere a process is supposed to run on schedule and its failure leaves no visible trace, a heartbeat is the right answer. A few typical candidates from agency life. **Database backups** are the classic: nightly, invisible, critical. **Data imports and exports**, say a nightly sync between shop and inventory system, fail silently until the stock counts stop matching. **Cache warmers and scheduled cleanups** keep a site fast and tidy; their failure shows up only gradually in poor performance. **Recurring reports and billing runs**, a script that generates invoices monthly or sends reports, mustn't skip a month unnoticed. **Certificate or token renewals** running via cron are especially treacherous: their silent failure only becomes visible when something expires and suddenly nothing works. The connecting pattern is always the same: a scheduled process whose success no one actively sees and whose failure hurts only with a delay. For every one of them, the same simple cure applies: a heartbeat at the end of the script, an expected interval in the monitoring. Every scheduled process whose failure leaves no trace deserves a heartbeat. See how cron jobs, backups, and imports can be monitored with expected intervals and confirmed alerting. ## Why this is a liability issue for agencies For an agency, an unnoticed backup failure isn't just a technical annoyance. It's a silent risk with real consequences. The moment a backup is needed is, by definition, a crisis moment: a server has failed, data is lost, a migration went wrong. To discover in exactly that moment that the last three weeks of backups are missing turns a manageable mishap into a catastrophe. And the question then on the table isn't "why did the server fail?" but "why didn't *you* notice the backups weren't running?". That's precisely where the value of a heartbeat reaches beyond the purely technical. It shifts responsibility from "we hope the backups run" to "we know they run, and we're told the same day if they don't." That certainty is something you can stand behind with your client, and it protects you in the conversation that inevitably comes when things go wrong. A backup whose run is confirmed every day is a provable promise; a backup that "should be running" is a hope. For agencies that operate critical infrastructure for their clients, monitoring silent processes is therefore not a technical extra but part of the duty of care. The effort, one line per script, is out of all proportion to the risk it catches. An unnoticed backup failure becomes a liability issue the moment the backup is needed. A heartbeat shifts the situation from "we hope it runs" to "we know, and we're warned immediately". A hope becomes a provable promise. ## From blind spot to complete visibility The real gain of this approach is that it closes a blind spot many don't know they have. Most monitoring strategies cover the visible: websites, servers, services that answer when you ask. The silent processes in the background, that no one asks and that never report on their own, stay out of view. They run on the assumption that they're running, until one day that assumption is disappointed. A dead man's switch closes that gap with minimal effort and inverts the very principle that makes it necessary: instead of waiting for a problem to get loud, you make the silence itself audible. Every expected heartbeat that fails to arrive becomes an early, clear warning, long before the consequence shows up. For every scheduled process that matters to your client, that's the difference between "we caught it in time" and "we caught it too late." In the end it's about the same stance as all of monitoring: not being surprised. The only difference is that silent processes are the ones guaranteed to surprise you without a heartbeat, and at the worst possible moment. One line in the script closes exactly that gap. Close the blind spot in your monitoring. See how Uptimeify monitors cron jobs and backups via heartbeat, EU-hosted, with the same confirmed alerting as your other monitors.