The problem
Most backups fail quietly. The script runs at two in the morning, writes a file or doesn't, and exits. Nobody reads the log. Weeks later someone needs a restore and finds the newest copy is months old.
A cron job has the same problem. It runs on a server you rarely log into. If it stops running, nothing tells you. The scheduler doesn't send a message saying a job never started. The work just doesn't get done.
Checking by hand doesn't scale. Solo developers and freelancers who look after several client sites end up with a list of things to remember, and the list goes stale. Small teams have the same issue. Whoever set the job up has moved on, and the person who gets woken when it breaks may not know it exists.
What you need is a way to find out when something has not happened. Most monitoring watches for things that do happen, such as an error or a site going down. A heartbeat watches for silence.
How it works
A heartbeat monitor is a simple idea. You give it a name and a schedule, for example "nightly database backup, every 24 hours". Your job then makes a request to a unique address when it finishes successfully. Each request is a heartbeat. If the expected heartbeat does not arrive within the window you set, AperioFlow raises an alert.
This suits two kinds of work well.
Cron jobs. Add one line to the end of the script, after the work has completed. If the script crashes halfway, that line never runs, no heartbeat is sent, and you hear about it. Put the request after the real work, not at the top. A script that starts and then fails will otherwise look healthy.
Backups. The same rule applies. Send the heartbeat only after the backup file has been written and, if you can, after a basic check that it is not empty. A backup that writes a zero-byte file and then pings is a success that helps nobody.
Choose the grace period with care. It is the time you allow beyond the schedule before an alert goes out. A nightly job that usually takes ten minutes needs a window longer than ten minutes, but not so long that a missed run sits unnoticed until the next morning. Too tight and you get false alarms, which teaches people to ignore alerts. Too loose and the point is lost.
Alert emails go only to people in your organisation. That matters when an alert names a client's system, and it means the person who receives it is someone you chose to add.
Getting started
Start with the job that would hurt most if it stopped without anyone noticing. For many people that is the database backup. Work through a short list:
- Pick one scheduled job or backup.
- Create a heartbeat monitor for it in AperioFlow and give it a clear name, such as the client and the task.
- Set the schedule and grace period to match how long the job really takes.
- Copy the address the monitor gives you and add a request to it at the end of the script, after the work succeeds.
- Run the job once by hand and check that the monitor records a heartbeat.
- Test the alert. Let a run fail on purpose, or skip the request once, and confirm the message reaches the right person.
Do the test. Many people set up monitoring and never check that the alert arrives. It takes a few minutes and tells you whether the setup works.
Keep the list short at first. The free plan includes 10 monitors, which is enough to cover the backups and cron jobs for a small set of sites. If your team needs to share the same monitors, the team price is 29 pounds a month flat for up to 10 people, as on the pricing page.
Write down what each monitor is for and where its script lives. When you change a schedule months later, those notes will save you time.
Where your data sits matters to some teams. AperioFlow is run from the UK and hosted in France. You can download your data, so you are not tied in if you decide to leave.
Tweed Tyne runs its own work on AperioFlow, so the product is in daily use before it reaches your jobs.
Start free at https://app.aperioflow.co.uk/#/signup and set up your first heartbeat monitor.