Reliability engineering assumes a team on call. It doesn't have to. Automating the incident lifecycle so that a solo operator can sleep through the night — most nights.
Traditional reliability engineering is staffed like a fire department: rotations, escalation tiers, war rooms. A solo studio has none of that — which sounds like a weakness until you realize it forces the correct question early: why does this system need humans to stay up at all?
The one-person playbook starts by refusing the premise. Every alert that could ever page you is a design defect filed against yourself. The goal is not faster response; it is fewer reasons to respond.
Most incidents are boring: a dependency hiccup, a memory spike, a certificate expiring. These deserve no human attention. Health checks that restart, proxies that fail over, deploys that roll back on failed probes — the boring incidents should resolve before you would have opened the dashboard.
Reserve human attention for the genuinely novel. If an alert fires more than twice, it graduates from notification to automation or gets deleted. A page list you can count on one hand is a feature, not a risk.
With no teammates to triangulate, your telemetry must reconstruct the incident for future-you: structured logs with correlation IDs, metrics with sane defaults, traces on every cross-boundary call. Post-incident review becomes reading, not archaeology.
Keep the stack boring on purpose. One metrics store, one log sink, one dashboard. Reliability tooling sprawl is how teams of ten justify their size; a solo operator chooses the opposite trade.
Write down, before anything breaks: what the system promises, what it may lose, and who gets told. A solo SRE who has pre-decided the recovery contract acts decisively under pressure; one who improvises negotiates with themselves at 3am and loses.
Why shipping with fewer options produces better products. A case for designing the boundaries first and letting the product emerge from them.