I thought detecting failed cron jobs was the hard part. Avoiding noisy alerts is harder.
I’m building MissedRun, a small cron / scheduled job monitoring tool.
At first I thought the main problem was simple:
“Detect when a job does not run.”
But the more I build it, the more I realize the annoying part is not only detection.
It is avoiding noisy alerts.
Some examples I ran into:
- a job sends a failure ping multiple times
- a job starts, but never sends success
- a job is late, then recovers
- a monitor is paused, so it should not alert
- the checker runs every few seconds, but should not send duplicate emails
- a “start” event should not reset a real failure
- email delivery itself can become unreliable
So the product starts to become less about “cron monitoring” and more about state handling.
When is something really failed?
When is it just running?
When should the alert be sent once?
When should it reset?
The tricky part is that the user does not care about the internal state machine. They only care about getting one useful alert at the right time.
Too few alerts, and the tool is useless.
Too many alerts, and people stop trusting it.
I’m curious how other founders handle this in small SaaS products.
If your product sends operational alerts, do you keep the logic simple, or did you also end up building a state machine around it?
For context, this is the project:
https://missedrun.com
