I built a tiny tool to monitor cron jobs and scheduled tasks — looking for feedback
Hey everyone,
I recently built the first V1 of MissedRun — a small tool for monitoring cron jobs, scheduled scripts, imports, backups, ETL jobs, and other recurring background tasks.
The idea is simple:
- you create a monitor
- you get a ping URL
- your cron job or script calls that URL when it runs
- if the ping is late, missing, or reports failure, MissedRun marks the job as needing attention
I built it because I’ve had background jobs silently fail before, and I wanted a very simple way to see whether scheduled jobs are still alive.
The V1 currently has:
- monitor creation
- ping URLs
- start / success / fail pings
- late / missed / failed statuses
- monitor history
- basic account system
- docs with curl / bash / Python examples
It is still very early, so I’m not trying to make a big launch yet. I’m mainly looking for feedback from developers, indie hackers, and people running cron jobs or background tasks.
I’d love to know:
- Is this problem something you’ve dealt with?
- Is the current V1 clear enough?
- What would be the minimum feature that would make you actually use it?
Site:
https://missedrun.com
Thanks — any honest feedback would help a lot.
Trending on Indie Hackers
The idea is solid, but I think the challenge is positioning.
Monitoring cron jobs feels like a “nice to have”, but preventing silent failures in things like billing, backups, or data sync is a “must have”.
Framing it around risk and business impact might make it much more compelling.
Also, it might help to focus on a specific audience first (e.g. startups or dev teams) instead of keeping it broad.
Thanks, that makes a lot of sense.
I agree that “cron monitoring” sounds too small / nice-to-have, while the real pain is silent failure in important recurring work.
I’m thinking about positioning it more around:
“Know when scheduled jobs fail, get stuck, or never run.”
The first audience I’m considering is small SaaS teams and solo developers running things like imports, backups, billing syncs, reports, and background scripts.
That feels more specific than trying to target everyone who uses cron.
The operational risk here is bigger than “cron monitoring.”
Once this is in production, it stops being a ping checker.
It becomes a reliability layer for everything nobody notices until it breaks:
backups
imports
billing jobs
webhooks
queue workers
syncs
That shift matters because people don’t buy this to monitor cron.
They buy it to avoid silent operational failure.
“MissedRun” explains the symptom.
It does not carry the weight of the problem once this expands beyond simple cron checks.
As soon as this moves upmarket, the product likely outgrows the current name.
Vroth.com would carry this much better.
Shorter, harder, more infra-native, and better suited for something sitting in the reliability / ops layer rather than a utility tool.
This is really useful feedback, thank you.
You’re right that the bigger problem is not “cron” itself, but silent operational failure around recurring work: backups, imports, billing jobs, webhooks, syncs, queue workers, and similar tasks.
I’m still trying to decide how broad the product should become. My instinct for the V1 is to stay very focused and make the simple case extremely clear first: scheduled jobs that fail, get stuck, or never report.
I see your point about the name though. “MissedRun” explains the symptom, but it may not fully carry the broader reliability / ops layer idea if the product expands.
For now I’ll probably keep the name while validating the core use case, but this gives me a lot to think about for positioning.