Receive proactive alerts when your openclaw instance is unavailable

When openclaw breaks, it isn't always obvious right away. You might be waiting for a response, or just not actually doing anything at the time. It isn't like a typical web service where you can use uptime monitoring to see if the url is still up. You can monitor the gateway, but that monitors part of your openclaw infrastructure.

I use a heartbeat check to keep an eye on my openclaw instance and make sure it is all working. I am not referring to heartbeat.md, but this process will use that as well. Healthchecks.io is the best way to do these checks, a free account gets 20 checks. If you use Uptime Kuma, you can also use that.

A heartbeat check is the opposite of a typical up/down monitor, it expects a ping every so often, if it doesn't receive one, it will send an alert. This pattern is really good for backups and other scripts where you want to be notified when they don't run properly. If a heartbeat isn't detected in a certain time period, you know something is wrong.

Here is the pattern in action:

Openclaw will typically monitor heartbeat.md every 30 minutes, and run regular tasks that need to be run many times a day, like checking email. I rarely use heatbeat.md as cron is almost always a better choice. However for this job, heartbeat.md is a good choice.

How to set up monitoring

First you need to create a check in Healthchecks.io, you can use a free instance or run your own local install.

Once created, you will get a url that you need to visit every 30 minutes or the system will send an alert if it hasn't heard from anyone in an hour.

Then tell your agent to curl this url in heartbeat.md, no output is needed.

That's it!

If your openclaw is broken, or your LLM is not responding, or any configuration issue is present, it won't process this heartbeat and you will get an alert within an hour. You can also reduce the grace period to be 32 minutes, and be alerted a lot quicker on a single failure.

You will need to adjust the grace period based on your openclaw's heartbeat, which defaults to 30 minutes.

This is also a good way to make sure your heartbeats are firing properly. Using cron is also a perfectly valid option. In fact, I use cron exclusively as it is almost always a better choice and will drastically reduce your token usage.

Heartbeats run in your agents context where as cron jobs can run in main agent's context or in an isolated context. This subtle difference is massive for "token burn", as you can be sending tens of thousands or even hundred thousand tokens just to do a simple curl command when using a heartbeat. At 30 minutes, this means 48 events in your main agent's context window.

If you change your mind later, you can easily move it to an isolated cron job. Your agents should be able to handle this.

If you want to test your heartbeats are working as well as the rest of openclaw workflow, use heartbeat.md. If you want to optimize token burn, use an isolated cron job.