Monitoring Cron Jobs with Heartbeats

Let me tell you about a problem that drove us crazy for years before we finally solved it. You’ve probably experienced it too - you have these background jobs running on your servers, doing important stuff like backing up your database every night, sending out scheduled emails, or cleaning up old files. And for the most part, they just work. Until one day, someone asks “hey, when was the last time we got a backup?” and you realize the job has been silently failing for two weeks.

This is the thing about cron jobs and scheduled tasks - when they work, nobody notices. When they fail, they often fail quietly. There’s no error page, no angry user complaint, no obvious sign that anything went wrong. The job just… doesn’t run. And traditional monitoring doesn’t help here because there’s nothing to monitor. You can’t alert on an error if the code never even executes.

The Idea Behind Heartbeat Monitoring

So we built heartbeat monitoring, and the concept is beautifully simple once you hear it. Instead of waiting for something to go wrong and then detecting it, you flip the whole thing around. You tell Loggy “hey, this job should run every hour” and then your job pings Loggy every time it completes successfully. If Loggy doesn’t hear from your job when it expects to, that’s when we know something’s wrong.

Think about it like checking in with a friend. If you have a buddy who texts you every morning, and one day you don’t hear from them, you’d probably check in to make sure they’re okay. That’s exactly what heartbeat monitoring does for your scheduled jobs. Silence becomes the signal that something needs attention.

How to Set It Up

The setup process is intentionally dead simple because we wanted this to be something you could add to an existing job in about thirty seconds. First, you create a heartbeat in Loggy. Go to the Heartbeats page, click Add Heartbeat, and give it a name that actually describes what the job does - something like “Nightly Database Backup” or “Hourly Report Generator.” Then you set two things: how often the job should run (the expected interval), and how much wiggle room to allow before we consider it late (the grace period).

The grace period is important because real-world jobs don’t always run at exactly the same time. Maybe your server is under heavy load and the job starts a few minutes late. Maybe there’s some variance in how long the job takes to complete. A grace period of five or ten minutes gives you a buffer so you’re not getting false alarms every time there’s a minor delay.

Once you’ve created the heartbeat, you’ll get a unique URL that looks something like https://loggy.dev/heartbeats/ping/your-heartbeat-slug. All your job needs to do is hit that URL when it finishes successfully. Here’s what that looks like in practice:

curl -X POST https://loggy.dev/heartbeats/ping/nightly-backup

Or if you’re doing it in code:

await fetch('https://loggy.dev/heartbeats/ping/nightly-backup', {
  method: 'POST'
});

import requests
requests.post('https://loggy.dev/heartbeats/ping/nightly-backup')

Notice there’s no authentication required for pings. We made this choice deliberately because we wanted the ping to be as simple as possible to add to any script, in any language, on any system. The URL itself is unique and unguessable, so it’s secure enough for this purpose.

Understanding the Different Statuses

When you look at your heartbeats in Loggy, each one will show one of four statuses, and it’s worth understanding what each one means.

Healthy means everything is working as expected. We’re receiving pings on schedule, and your job is doing its thing. This is the status you want to see.

Late means we haven’t received a ping yet, but we’re still within the grace period you configured. This might mean your job is running a bit slow today, or it might be the early warning sign of a problem. We won’t alert you yet, but we’re watching.

Down is when the grace period has passed and we still haven’t heard from your job. This is when you’ll get an alert (if you’re on Pro or Team), because at this point something is definitely wrong and needs your attention.

Pending is what you’ll see when you first create a heartbeat, before it’s received its first ping. Once your job runs and pings Loggy for the first time, it’ll move to one of the other statuses.

Some Tips From Our Own Experience

We use heartbeats internally for all of our own scheduled jobs, so we’ve learned a few things about what works well.

The most important thing is to put the ping at the end of your job, not the beginning. You want to know that the job actually completed successfully, not just that it started. If your backup script pings Loggy and then crashes halfway through, you’d never know there was a problem. But if it only pings after the backup is verified and uploaded, then a missing ping actually means something went wrong.

When you’re setting intervals, be realistic about how your job actually runs. If it’s a cron job scheduled for every hour, set the interval to 60 minutes. If it runs every day at midnight, set it to 1440 minutes (24 hours). And always add a reasonable grace period - we usually go with about 10% of the interval, so a 60-minute job gets a 5-10 minute grace period.

Finally, start with your most critical jobs. You probably have a lot of scheduled tasks running, and you don’t need to monitor all of them right away. Focus on the ones where a silent failure would actually cause problems - database backups, payment processing, anything that affects your users or your data integrity.

Getting Notified When Things Go Wrong

If you’re on the Pro or Team plan, you can set up alerts to get notified when a heartbeat goes down. We’ll send you an email so you can investigate and fix the problem before it becomes a bigger issue. You can configure your alert preferences in your settings, and you can even set up different notification rules for different heartbeats if some are more critical than others.

The whole point of all this is to give you peace of mind. Once you’ve got heartbeat monitoring set up, you can stop worrying about whether your background jobs are running. If something goes wrong, you’ll know about it. And if you don’t hear from us, that means everything is working exactly as it should.