I published the self-hosted version of my cron job monitoring tool
I published the self-hosted version of MissedRun.
MissedRun is a small tool for monitoring cron jobs and scheduled background jobs that fail silently.
The idea is simple:
- your job sends a start ping when it begins
- it sends a success ping when it finishes
- it can send a failure ping if something breaks
- if the expected ping never arrives, the job is marked as missing
I originally built it because one of my own background jobs stopped running and I only noticed the next day when the data looked wrong.
After thinking more about it, I realized that some developers may not want this only as a hosted service. For cron jobs, backups, imports, and ETL scripts, some people prefer to run monitoring on their own infrastructure.
So I moved the self-hosted repo under a GitHub organization and published the first v0.1.0 release.
The self-hosted version currently includes:
- Docker Compose setup
- FastAPI backend
- PostgreSQL storage
- monitor creation
- start / success / failure pings
- missing job checker
- basic email alerts
- event history
Self-hosted repo:
https://github.com/missedrun/missedrun-selfhosted
Hosted version:
https://missedrun.com
Still early, but I am trying to learn how other founders and developers monitor boring but important background jobs.
If you run cron jobs, imports, backups, billing syncs, or cleanup scripts, do you usually prefer hosted monitoring or self-hosted monitoring?
This is a useful devtools wedge because the pain is very specific: silent failures in boring background jobs that nobody checks until the data is already wrong. That is a much clearer angle than generic uptime monitoring.
I’d probably position MissedRun around “background job reliability” more than cron monitoring only. Cron is the entry point, but the real buyer pain is bigger: imports, billing syncs, ETL scripts, backups, cleanup jobs, and scheduled workflows that quietly stop working.
One thing I’d watch is the name. MissedRun explains the first use case well, but if this expands into a broader reliability layer for scheduled jobs and backend workflows, a harder infra-grade name like Davoq.com would give it more room than a descriptive tool name.
the fail-silently failure mode is the worst one — we caught a similar bug this week, an agent had been writing to a logging table for two months with nobody noticing the writes succeeded but nobody read them. curious what your default for jitter on the expected-ping window is, because cron drift on shared hosts feels like the place I'd worry about false misses.
Yes, exactly — that “everything looks fine but nobody noticed the job stopped doing the useful thing” case is what I’m most interested in.
The logging table example is painful because technically the job was running, but the business result was stale.
In your case, would a simple check-in monitor have caught it if the success ping was sent only after the real work finished? Or would you still need a separate check that verifies the expected output changed?