Monitors: Heartbeat and Cron Job Monitoring
A monitor expects a ping within an interval. Miss it and you get a late state first, then an alert. One curl call sets it up.
A monitor watches for a ping that should arrive on a schedule. Your job calls a URL when it finishes; if that call does not arrive within the interval you set plus a grace period, the monitor alerts.
This is the primitive that catches a job which never ran at all, which is the failure no error tracker can see. A process killed by the out-of-memory reaper, a container evicted mid-run, or a crontab lost in a server rebuild all produce the same output: nothing.
Setting one up
Creating a monitor issues an ingest token. Add one line to the end of your script and you are done. There is no agent, no SDK, and no library to keep updated.
Ingest is dual-authenticated. The token in the URL identifies which monitor, and the X-API-KEY header must match your account key. A leaked URL alone cannot be used to forge pings against your account.
Three states, not two
Most heartbeat tools are binary: up or down. That produces alerts for ordinary timing jitter, and an alert that cries wolf gets muted. SensaCat puts a state between them.
| State | Condition | Alerts? | Visible on dashboard |
|---|---|---|---|
| active | Ping arrived within the interval | No | Green |
| late | Past the interval, inside the grace period | No | Amber |
| silent | Past interval plus grace period | Yes, critical | Red |
The late state is the useful one during an incident. It tells you a job is currently overdue without paging anyone, which means an engineer already looking at the dashboard sees the problem before the alert fires.
A monitor's last_ping_at is set to its creation time at insert, so a monitor that has never been pinged is still evaluated correctly. A monitor you created and then forgot to wire up will tell you so rather than sitting green forever.
Grace periods, set per monitor
The grace period is a buffer in minutes past the expected interval. Size it from the job's longest observed runtime rather than picking a round number, because the trade is detection speed against false alarms and only you know your job's real variance.
A job running every 60 minutes that occasionally takes 11 minutes wants a grace period of 15 to 20. A job running every 5 minutes with a 30-minute grace period lets six consecutive runs fail before anyone hears about it.
Explicit failure reporting
Waiting for silence means waiting out the interval plus grace before anything happens. A job that already knows it failed can say so immediately.
This closes the gap that Dead Man's Snitch covers with exit codes and Cronitor with a dedicated call. You get fast alerting on loud failures and absence detection on quiet ones from the same monitor.
Self-healing
Any new ping flips a late or silent monitor back to active and resolves its open alert automatically. There is nothing to acknowledge and no state to clean up after a transient problem fixes itself.
Plan limits
| Free | Starter | Team | Enterprise | |
|---|---|---|---|---|
| Monitors | 2 | 15 | Unlimited | Unlimited |
| Grace periods | Yes | Yes | Yes | Yes |
| Explicit failure reporting | Yes | Yes | Yes | Yes |
| Alert retention | 7 days | 30 days | 90 days | Unlimited |
What a monitor does not tell you
A ping proves the script reached the line containing the ping. It says nothing about whether the work was correct. A nightly sync that fetched zero rows because an upstream API returned an empty array will ping exactly like a successful run.
Close that gap by having the job check its own output and report a failure explicitly, using the payload above. That is a two-line change and it catches the failure class nothing else does.
Background reading: heartbeat monitoring and grace periods. Start free.