The Silent Sentinel: Building a Heartbeat Monitor with a Cron Job and a Text File
We speak of our systems in grand terms: distributed, resilient, cloud-native. We deploy elaborate monitoring stacks that graph every conceivable metric, and yet, sometimes the most critical question is the simplest one: is the box itself still awake? Not just the web server or the database, but the very metal and silicon humming in the rack or the corner of the office. For the small service, the home server, the forgotten bastion host, we need a sentinel that asks this question, persistently and without fanfare.
We can build this sentinel from the most humble of parts: a cron job and a text file. The principle is straightforward. On the machine you wish to monitor, you set a cron job to run every minute. Its only duty is to touch a file, to update its last-modified timestamp. This file becomes the machine’s heartbeat, a steady, rhythmic pulse written to disk.
The Pulse and the Listener
The heartbeat alone is useless without a listener. On a separate, trusted machine—perhaps your own workstation or a small, always-on server—you run another script. This listener uses nothing more than `ssh` and `stat` to check the timestamp of the heartbeat file on the remote machine. It calculates the time elapsed since the last pulse. If that time exceeds a threshold, say five minutes, it knows the heart has skipped a beat. The machine may be dead, unreachable, or its cron service may have failed.
The elegance is in the separation. The monitored machine only needs to worry about its own simple, repetitive task. It requires no external APIs, no agents, no open inbound ports except for SSH. The intelligence, the worrying, is offloaded to the listener. This is a form of passive monitoring that asks for nothing but the most basic access.
The listener’s script doesn’t need to be complex. A few lines of Bash can retrieve the timestamp and perform the comparison. Its action upon failure can be as simple as sending an email or a message to a chat service, or as crude as making a phone ring with an old modem. The important part is that the alert comes from outside the potentially failing system. It is a witness, not a participant.
This technique is profoundly boring, and that is its greatest virtue. There are no services to keep running on the monitored host besides cron and sshd, which are fundamentals. There are no databases to maintain, no queues to watch. It is a single, unbroken chain of causality: a cron job triggers a file write, a remote script checks the file’s age. It is a protocol built on the immutable certainty of a filesystem timestamp. In the quiet hum of our small services, this silent sentinel stands watch, a testament to the power of a simple question, asked over and over again, and the profound peace that comes from knowing someone is always there to listen for the answer.
Notes & further reading
A few pages I came back to while writing this: