I built tools for the human side of on-call — testing if engineers will actually pay ($0 so far)
Most on-call tooling instruments the systems — alerting, runbooks, incident timelines. Almost nothing instruments the operator: the sleep you lost, the handoff done verbally so the next person rediscovers everything at 3am, the same service dragging you out of bed for the third time this quarter. That cost stays invisible until someone quits.
So I made two small things for on-call engineers:
- a free one-page On-Call Hygiene Checklist — five quick checks (~2 min), readable with no signup: https://steadystate.engineer/checklist/?ref=ih
- a $9 Incident Debrief Template pack — copy-paste templates that log what an incident cost the operator, so "on-call is rough" becomes a documented number you can actually argue with.
I'm being deliberate: this is a willingness-to-pay test, not a launch. The insight that nobody instruments the human cost of on-call, I'm fairly confident about. Whether engineers will pay for tooling around it is completely unproven: sales so far are zero. I'd rather learn that in a few weeks with a $9 product than talk myself into a business that doesn't exist.
Building in public means sharing the ugly part too: cold distribution as an anonymous new brand has been brutal. So part of why I'm here is to find out whether the idea lands somewhere that isn't gated against day-old accounts.
Provenance up front: This is AI-drafted, human-edited, built from public on-call discussions and incident-culture writing, this is not invented authors nor fabricated war stories.
What I'd genuinely value from this community:
- Does the free checklist look useful, or generic?
- Is $9 for the debrief pack a fair ask, too low, or would you not pay for this at any price? Blunt answers are the point.
- If you've carried a pager: does "log what the incident cost the operator" resonate, or is it overhead you'd never actually do?
The $9 test may be measuring the wrong buyer. Engineers experience the cost, while engineering managers control reliability budgets and staffing. Let engineers use the per-incident form free, then ask five managers to pay for a quarterly team summary built from those debriefs. A paid aggregate would validate a budget without asking responders to fund documentation of their own fatigue.
Nice Post
Thanks... do you have any comments on my questions? I would love to hear your opinion.
I like that you're measuring the cost of operating the system, not just the cost of the system failing.
Incident metrics usually tell teams what broke. Capturing what repeated incidents are costing the people responding to them creates a very different kind of evidence—one that's often missing when engineering teams decide where reliability work should actually go.
Right — that's the exact gap I keep bumping into. Postmortems are great at "what broke," terrible at "what did fixing it cost the person who fixed it." The prioritization angle you're pointing at is actually the harder sell than I expected: it's easy to get people to nod at "on-call's been rough," much harder to get a number that survives a planning meeting.
I am curious how this maps to your team, if you carry a pager — is the missing evidence you're describing something you'd log per-incident, or does it only become useful in summary (a quarter's worth, not one bad night)? And more bluntly: is this a $9 problem, a free-checklist problem, or neither?
Those are good questions.
I do have answers to them, but they're connected. I don't think I could answer one without the others or do the reasoning justice in a thread.
If you're open to it, what's the best email to reach you on?
hello@steadystate.engineer works well. Happy to keep it in the thread too if that's easier, but email is fine if the reasoning needs the space. Appreciate you taking the time on this.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.