Introducing Alwaysbeat

Hi — I'm Anton, and this is Alwaysbeat. It watches your cron jobs, backups, and scheduled tasks, and it taps you on the shoulder when one of them quietly stops running.

Let me be honest about why I built it, because there's no dramatic outage story here.

Mostly, I was bored, and I like monitoring. I find observability genuinely fun — the small puzzle of noticing that something is wrong before anyone has to come and tell you.

The other reason is more of an admission: I'm one person. I'm not going to build Datadog or New Relic — those are enormous, with the teams and budgets to match. But I kept looking at that whole world and thinking there's room for something much smaller. So instead of trying to boil the ocean, I picked one narrow, genuinely useful slice of observability — did my scheduled job actually run? — and built just that. Something small enough that I can support it on my own, and cheap enough to run that I can keep it cheap for you.

And it turns out that one small question is a real blind spot. When scheduled work breaks, it usually breaks quietly. The server reboots and the crontab was never persisted. A path changes. A token expires. The script exits early without an error anyone will ever read. There's no crash, no alert, no red light — the job just stops happening, and you find out at the worst possible moment.

Watch for silence, not for errors

Normal monitoring waits for something to go wrong: an error in the logs, a failed request, a spike on a graph. But a job that never starts doesn't produce an error. There's nothing to catch, because nothing ran.

Alwaysbeat turns that around. Your job checks in when it finishes, and Alwaysbeat watches for the check-in that doesn't arrive on time. If the ping is late, you hear about it. A job that dies before it can say a single word is exactly the case this catches — which is precisely the blind spot I wanted to close.

The whole idea in one line

You add a curl to the end of your job:

# run the backup; if it exits 0, tell Alwaysbeat we're still alive
0 3 * * *  /usr/local/bin/backup.sh && curl -fsS https://ping.alwaysbeat.com/ping/<your-uuid>

That's genuinely it. Alwaysbeat works out when the next ping is due from your schedule. A sweeper checks every minute, and if a job is overdue past the grace period you allowed, the check goes down and you get a message. The next successful ping brings it back up and sends an all-clear.

A few things I made sure to get right

• Real schedules with real timezones. Intervals like "every hour," or cron expressions pinned to an actual IANA timezone — and Daylight Saving Time is handled properly, not fudged. (More on that in a separate post, because it turned out to be the fiddliest part.)
• Signals that match how jobs actually behave. Report success, a start, an explicit failure, or a command's exit code — all with a plain curl.
• Alerts where you already are. Email, Telegram, Slack, or a signed webhook you can point at your own systems.
• Controls for noise. Grace periods, a flap cooldown for jobs that briefly wobble, repeat reminders, and "this run took too long" warnings — because a monitor you don't trust is worse than no monitor at all.
• An API, not just a dashboard. I wanted to create checks from scripts and infrastructure code, so that's a first-class way to use it.

Give it a go

Your first check takes a couple of minutes. The Quick start walks you through it, and the docs cover the rest. If you kick the tyres and something feels off, I genuinely want to hear about it.

I built this as a small, focused tool by one person who likes monitoring — not another giant observability platform. I think there's real value in that. Hopefully you do too.

— Anton