steadystate

Operational tools for the human side of on-call. Checklists, templates, and field guides for the people who carry a pager — instrument the rotation the way you instrument the system.

state: steady · also monitored: the operator

What this is

SteadyState makes operational tools for the human side of on-call — for SREs, platform and DevOps engineers, and anyone else who carries a pager. You already instrument your services; these point the same instinct at the rotation itself: handoff hygiene, alert-noise triage, incident debriefs that log what an incident cost the operator, and protecting recovery between rotations.

Not meditation-app material. Not corporate wellness. Structured, reusable tools — closer to a runbook than a self-help book.

Why it exists

Every part of on-call has tooling — except the operator. There are runbooks for the system, alerting platforms, incident tools, schedulers. The one thing nobody instruments is the human cost: the handoff that happens in a hallway instead of in writing, the alert noise nobody's tuning, the bad night whose cost never gets logged, the off-week that isn't actually off.

These are operational problems with operational fixes, but they sit in a blind spot — too "soft" for the platform backlog, too specific for generic wellness. One of the most-cited resources on the human side of on-call is still a conference talk from 2018. That gap is why SteadyState exists.

How this is made

You should know exactly how the content you're reading gets produced. Plainly:

  • Drafted with AI assistance. We use AI language models to draft content. We're not going to pretend otherwise.
  • Reviewed by a human, every time. Every piece is reviewed, edited, and approved by a human before it's published. Any physiological or health-adjacent claim is flagged during drafting and checked against a source before release. Nothing ships on autopilot.
  • Grounded in real engineers' words. Content is built from documented community experience — pain points collected verbatim from public engineering communities (r/sre, r/devops, and similar), incident culture, and published research. Where a claim needs a source, we link one.
  • No fake authority. We don't invent authors, credentials, or war stories. You won't find a stock-photo founder with a fabricated biography here. What we publish stands on its sources and its usefulness — judge it on that.

What we will never do

  • Dress an ad up as advice — affiliate links are always disclosed, and we only recommend things we'd defend in a public comment thread
  • Play games with your data — no tracking-heavy pages, and your inbox is not a growth metric
  • Invent authors, credentials, or war stories we didn't live
  • Pretend an operational tool is a substitute for medical care when the problem has outgrown one

Products

  • The On-Call Hygiene ChecklistFree Free

    A two-minute self-audit of your rotation — five checks across handoff, alerts, debrief, recovery, and recurrence. Every unchecked box is where the next incident gets more expensive than it needs to be. Start here.

    Get the free checklist →
  • The On-Call Survival Field Guide $19

    A runbook for the human, not the system. The full field guide for the human side of on-call — pre-rotation prep, the 3am page, alert-fatigue triage, protecting recovery, and escalating the structural stuff as a reliability issue your org owns.

    Get it on Gumroad →
  • The Incident Debrief Template $9

    The human-factors half of your postmortem. Four copy-paste templates (plain text + fillable Word) that log what an incident cost the operator — night-of, structured personal, blameless team, and a running log.

    Get it on Gumroad →

A note on scope

SteadyState makes operational tools, not medical advice. On-call strain is real, and it can overlap with conditions that deserve proper clinical attention. If what you're carrying is heavier than a checklist or a debrief can help with, talk to a qualified professional — and if you're in crisis, contact your local emergency services or a crisis line now.

Who runs this

SteadyState is an independent publication run by a solo operator with a software-industry background. The "we" on this site is one person plus a review process — no staff writers, no content farm, and a strong opinion that engineers deserve better tools for the human side of on-call than "have you tried meditating?"

Questions, corrections, or feedback: hello@steadystate.engineer. Corrections are taken seriously and applied fast.