Hi Anders,

The hard part wasn't the checks themselves, it was that these are two opposite directions of signal. With cron jobs, heartbeats, and background jobs, your system talks to us. With uptime checks, we go out and talk to your system. And event-driven jobs have no schedule at all, so there's nothing to be late against.

What made it click was deciding that everything becomes a ping. An uptime check that fails writes a ping. A background job that hangs past its max duration writes a ping. From there, one pipeline handles all four types: same incident logic, same tolerance settings, same alert routing, same status pages.

Hi Johan,

Great question. Spotting missing activity in an event-driven job is genuinely tricky.

Our event-driven monitors natively detect failures, job duration, and success rates. For missing executions, you have two options depending on your setup:

If you can instrument the enqueue step: send a start ping with a run ID at the moment you enqueue the job, then a success or fail ping when it finishes. Set a max duration on the monitor, and if the run never completes within that window, we flag it. This catches jobs that get queued but never actually execute.

If you can't send a start ping: put a heartbeat monitor on top of your event-driven job and set its interval to the longest stretch of silence you'd consider normal. It's a workaround, but it works well as long as you don't need the volume factor.

For the volume side, our roadmap includes a setting along the lines of "this job should run at least X times in Y period," which will cover the cases neither approach above handles.

Happy to help you set this up if you need.