Deadhand
Cron, uptime & security drift in one monitor — flat pricing
Hey IH 👋
I'm a developer, and I'm validating an idea before I write a line of product code. I want your honest feedback more than your encouragement.
This one's personal. I've been burned by silent failures more than once. A cron job of mine stopped running and I didn't notice for weeks — found out only when the data it was supposed to produce just… wasn't there. Another time a deploy quietly stripped a security header; the site kept "working," nothing alerted me, and I only caught it by accident much later. The loud failures get caught. The silent ones are the ones that actually hurt — and I kept being the last to know.
So I started building the thing I wished I'd had.
Cron + uptime tools already exist (Cronitor, BetterStack, etc.), so I'm not trying to out-feature them. The wedge is the leg nobody else does: security drift. You baseline an endpoint (security headers, cookie flags, redirects, exposed paths like /.env), and it alerts only on regression vs that baseline — a tripwire for "today is less safe than yesterday." Not a pentest. Just "did this deploy make you worse off?"
Two deliberate bets, both from my own frustration: flat pricing (per-monitor pricing punishes solo devs like me), and staying narrow on purpose — no status pages, no on-call, no APM. One tool, three silent failures, then stop.
Right now it's just a landing page + waitlist. I'm doing the unsexy thing first: finding out if this is a real pain for other devs, or just mine.
This is where I need you. Be brutal:
- Have silent failures ever burned you the way they burned me — or am I scratching an itch only I have?
- Is "security regression after a deploy" something you'd pay flat for, or a nice-to-have you'd never actually buy?
- Is cron + uptime already "good enough," making security drift a hard sell?
Landing if you want to tear it apart: https://deadhand.app/?utm_source=indiehackers&utm_medium=post&utm_campaign=validation
I'd genuinely rather hear "nah, wouldn't use it" now than build the wrong thing for three months. Fire away.
4 Comments
What stood out to me is that several different conclusions still seem capable of surviving the same experiences.
A developer gets burned by a silent failure.
One person concludes the missing piece is monitoring.
Another concludes it's process.
Another concludes it's ownership or visibility.
That's what I'd be most careful with this early.
Not whether the pain is real.
What explanation is currently earning the right to shape the product.
Thank you, this really landed - you poked at the thing I’d been least careful about. The same burn really can “validate” different fixes, and “more monitoring” is just one of them. I caught myself treating the pain being real as proof that my explanation was the right one - and those are two different things.
Honestly, I haven’t separated them yet. There’s been no real validation traffic so far.
If you were in my place, how would you listen to people to hear which explanation is actually driving them? What would you be paying attention to?
That's actually the question I'd spend most of my time on.
Not because there's a single right answer, but because different answers can justify very different products.
Probably more than I'd try to unpack properly in a thread though.
If you'd like to continue, feel free to drop your email.
Worth adding: Healthchecks proves “just alerts” is a real product - but it’s free and open-source, so it never has to differentiate. The moment you charge, alerting stops being a feature and becomes table stakes - everyone has it. So the open question isn’t “do I alert,” it’s what someone actually pays to know when free already covers “you’ll find out.” That’s the thing I still need to validate.