I built a cron job monitor. Now I'm trying to figure out who actually loses sleep over this problem.
Hey everyone,
I've been building MissedRun for a few months — a tool that alerts you when scheduled jobs fail silently. Cron jobs, backups, imports, ETL pipelines, billing syncs. The kind of jobs that just disappear without throwing an error.
The technical problem is clear to me. I've lived it. A backup stopped running after a server restart. An import never ran because credentials expired silently. I found out days later when data looked stale.
But here's where I'm stuck.
I don't know who feels this pain strongly enough to pay for a solution.
When I talk to developers, most say "yeah that's annoying" — but annoying doesn't convert. I need to find the person who lost something real because of a silent job failure. The person who had to explain to a client why their data wasn't updated. The person who discovered their backups hadn't run in three weeks only when they actually needed one.
What I've tried:
I've been posting in r/selfhosted, r/sysadmin, r/devops. I get some views, some nods, but mostly people who already have a solution — even if it's just grep-ing logs manually and hoping for the best.
My question for this community:
For those of you who found your first paying users — how did you know you were talking to someone with a real problem versus someone who was just being polite?
And specifically — if you run scheduled jobs in production, do you have something that tells you when they stop running? Or do you find out the hard way?
Self-hosted version: https://github.com/missedrun/missedrun-selfhosted
Hosted version: https://missedrun.com
The real buyer here is probably not “developers who run cron jobs.” That group will agree with the pain but still default to scripts, logs, uptime checks, or self-hosted hacks.
The sharper ICP is whoever owns operational reliability for client-facing data, billing, backups, imports, reporting, or syncs. Silent failure is not painful because a job missed once. It is painful because nobody knows until a customer, client, or finance process exposes the gap.
I’d position MissedRun less like a cron monitor and more like a silent failure alert layer for business-critical background jobs. That makes the pain feel more expensive and less “nice-to-have.”
One thing I’d watch is the name. MissedRun explains the feature well, but if this becomes broader job reliability infrastructure across imports, ETL, backups, billing syncs, and workflows, Davoq .com would carry the backend/reliability angle with more weight.
On your first question — the signal I learned to trust was unprompted specificity. "Yeah that's annoying" is polite. "Last Tuesday our Stripe reconciliation cron didn't fire and I found out when a customer emailed about a double charge" is real. If someone can't tell you the exact incident, they don't have the pain badly enough to pay.
Follow-up question I started asking that filtered hard: "What did you do about it the last time this happened?" If the answer is "nothing, I just deal with it," they won't buy. If the answer is "I built a janky script" or "I now check it manually every morning," you've found someone who's already paying a cost — in time or anxiety — and your product is just a better price.
For MissedRun specifically: I'd skip r/sysadmin and go where the failures get expensive. Small SaaS founders running billing crons. Agencies running client ETL pipelines. Anyone with SLAs. The pain isn't "cron failed" — it's "I had to email a client about missing data." Sell to whoever writes that email.
This is really useful, thank you. The "unprompted specificity" filter makes a lot of sense — I've been getting a lot of "yeah that's annoying" responses and wasn't sure what to make of them.
The SaaS founders angle is interesting. Do you have a sense of where those people actually talk about this stuff? I've been in r/sysadmin but that's clearly the wrong crowd based on what you're saying.