Treat Your Morning Alarm Like an SRE Treats Uptime

Site reliability engineering treats an unreliable habit the way it treats an unreliable service: as a system with an undefined error budget, unaddressed single points of failure, and no bounded recovery time — a diagnosis, not a character flaw. Fix those three properties and the habit’s failure rate drops for the same reason a service’s uptime improves once a team stops depending on individual heroics to keep it up.

I’ve spent a chunk of my career on call for systems that were not allowed to go down quietly. Pager goes off, dashboard turns red, you have a runbook and a clock. What struck me, the first month I was also trying to fix my own 6:15 AM wake-up problem, was how much better the on-call framework explained my mornings than anything in the productivity literature did. Habit advice kept telling me to want it more. SRE doesn’t ask a service to want it more. It asks what fails, how you’d know, and what happens next.

The habit is a service. Waking up is the SLO.

In SRE terms, a service level objective (SLO) is the target reliability you’ve committed to — say, 99.9% of requests succeed. An error budget is the inverse: the 0.1% you’re allowed to fail before anyone acts. It’s a number, not a feeling — an explicit, pre-agreed tolerance that turns “did we fail?” into a measurable question instead of a vibe.

Most people’s wake-up habit has no SLO and, worse, no error budget — which sounds like it should mean zero tolerance for failure, but in practice functions as an unenforced one. Nobody is tracking the failure rate, so nothing trips when it climbs. You don’t find out your wake-up reliability has degraded from 90% to 60% over a season, because nobody was computing the number. Contrast that with a real SLO: “I am up and moving within 10 minutes of the alarm at least 26 out of 30 days this month.” Stated that plainly, you can actually miss it — and missing it is information, not just a bad morning.

This is the first move in the framework, and it’s less about discipline than instrumentation: name the metric before you try to hit it. A habit you haven’t defined numerically can’t be said to be failing, because there’s nothing for it to fail against. It just quietly erodes.

Single points of failure are not a moral failing, they’re an architecture choice

A single point of failure (SPOF) is any component whose failure takes down the whole system, with nothing else positioned to catch it. In production systems, engineers hunt these down deliberately — a lone database with no replica, a single availability zone, a config file that only one person knows how to edit. The fix is never “ask the database to be more reliable.” The fix is redundancy: a second component that fails independently of the first.

A phone alarm on a nightstand, alone, is a SPOF in exactly this sense. Phone alarms are reliable enough in isolation; the fragility sits in having only one of them evaluate a single question — “did the alarm go off and did I respond to it” — through one component, one failure mode: you, half-asleep, making a decision your fully awake self didn’t get a vote on. If that one link doesn’t hold, nothing else in the system catches it, because there is no something else.

The redundancy fix people reach for first is usually wrong in a specific, diagnosable way, and it’s the same mistake a six-layer backup chain built for a flight you can’t miss is designed to route around: five alarms, three minutes apart, same phone, same nightstand, same room. Five copies of the same failure mode don’t add up to redundancy in any sense SRE would recognize. In distributed systems this is called a correlated failure — multiple “backups” that all sit behind the same underlying dependency, so they all go down together. If the failure mode is “I silence alarms in my sleep without waking up,” having five of them changes nothing, because the thing that fails (semi-conscious dismissal) is the same across all five. Real redundancy requires an independent failure domain — a second component that breaks for a different reason than the first. A second alarm across the room addresses “I can reach it without waking up.” A second alarm requiring a physical action — standing up, scanning a code, walking to another room — addresses a different failure mode again. Stack failure domains, not copies of the same one.

This overlaps with, but isn’t identical to, the case for scoring a wake-up system on how many single points of failure it has and whether it escalates when ignored — that scoring exercise tells you how many independent failure domains you’re missing, while what follows here is about what still breaks even after you’ve stacked several. Specifically: an alarm and its redundancy usually both terminate at the same decision point — you, deciding whether the thing you were supposed to do actually happened. If nothing checks that decision from outside your own head, you’ve built redundant signal delivery on top of a single point of failure in verification. A production system doesn’t just retry a failed request more times; healthy ones use an external check that confirms success independent of the system reporting on itself. Self-reported success is exactly the kind of thing SRE teams learn not to trust, because the reporter has every incentive — often nothing sinister, just cognitive load and inertia — to mark the check green.

This is worth being concrete about, because it’s easy to gesture at “external accountability” without naming what property it actually adds. DontSnooze works, in this vocabulary, by injecting a dependency the wake-up system didn’t have before: a required verification step performed by something other than the component being tested. You send real-time proof — not a self-report — to a small group, and if the check doesn’t complete, a consequence fires automatically. The same move underlies a health check that requires a second reviewer to confirm status rather than letting a service mark itself healthy: verification decoupled from the thing being verified, which self-reporting never has.

Error budgets change what “trying harder” means

Once you have an SLO and you’re tracking misses against it, the error budget stops being abstract. Say your target is 26/30 mornings. If you’re at 28/30 by the 20th of the month, you have slack — an actual, quantified amount of slack, not a vague sense that you’re “doing fine.” If you’re at 15/20, you’ve already blown the budget with ten days left, and the correct response in SRE practice is not “push harder on the exact same system” — it’s a change freeze on anything that adds risk, plus a focused look at what’s actually breaking. Nobody in a well-run on-call rotation responds to a blown error budget with “everyone just needs to want the pager less.” They ask what’s failing repeatedly and fix that component specifically.

Applied to a wake-up habit, this reframes the moment of failure. Missing your alarm on day 23 is best read as a data point about whether you’re inside or outside the month’s budget, rather than a referendum on your character — and the more useful follow-up question is whether this miss, in the context of the last 29 days, signals a trend that needs a redesigned system, or is just noise inside an acceptable band. This is the part self-help language tends to get backwards: it treats every miss as maximally meaningful, full stop, when a 90% target running at 88% needs a small fix and one running at 50% needs a different architecture, and those two situations call for completely different responses.

Blast radius: who and what does a single failed morning actually damage

Blast radius is the scope of what a single failure takes down with it — one failed API call that only affects the user who made it has a small blast radius; the same failure in a shared authentication service is enormous, because every other service calling it depends on it too. Engineers deliberately design to shrink blast radius: bulkheads, circuit breakers, isolated failure domains, so one bad component doesn’t cascade into an outage of everything else.

Most personal wake-up systems have an enormous, undesigned blast radius. Oversleep once and the first meeting gets rescheduled or missed, the gym session evaporates, the medication that’s supposed to happen with breakfast gets skipped, the kid misses the bus, and you start the whole day fifty minutes behind with the residue of that showing up in decisions you make at 4 PM. One failed wake-up cascades because nothing in the system contains it. The single alarm was quietly propping up the entire rest of the day, which is a bad design even when it works, because it means the day has zero fault tolerance built in.

The higher-leverage fix is shrinking what one failure is allowed to take down, rather than chasing more reliable waking up in the abstract. A go-bag by the door means an oversleep doesn’t also become a “can’t find my keys” failure. A meeting that can slip 15 minutes without real cost means a rough morning doesn’t cascade into a professional one. This is a genuinely underused move in habit design generally: instead of only hardening the habit, you can harden its neighbors so a miss stays local.

MTTR matters more than perfect uptime

Mean time to recovery (MTTR) is how long it takes a system to get back to a working state after something breaks. A mature SRE org doesn’t obsess only over preventing every incident — that target is usually irrational past a certain point of diminishing returns — it obsesses over shortening recovery time when incidents happen anyway, because incidents happening anyway is simply the expected condition, not a scandal.

This is the piece of the framework I think matters most and gets talked about least in habit writing, which tends to treat any lapse as something to prevent absolutely rather than something to recover from quickly. A wake-up system with a 20-minute MTTR — you oversleep, and twenty minutes later you’re dressed, caffeinated, and only mildly behind — is a better system than one with a 99% success rate and a four-hour MTTR on the 1% where it does fail, the day spirals, and you write the whole day off by 9 AM. The second system looks more reliable on paper and performs worse in the metric that actually costs you something: total degraded time across the month.

Building for fast recovery instead of only for prevention means having a defined “what does getting back on track look like” that doesn’t require the day to be perfect to be salvaged. It’s the difference between a system that has exactly one good outcome (wake up on time) and a system that has a good outcome and a fallback outcome that’s still fine.

Toil: the maintenance cost you’re not counting

One more term worth importing: toil, in SRE usage, is manual, repetitive work that scales linearly with usage and produces no lasting improvement to the system — the opposite of engineering work, which is a one-time investment that reduces future toil. Teams track toil explicitly because it’s insidious: each instance feels small, but the aggregate quietly consumes the capacity that should be going toward actually fixing things.

This is close to what a four-layer diagnosis of alarm compliance calls the Consequence Layer, approached from a different angle: negotiating with yourself every single morning — the internal argument about five more minutes, every day, indefinitely — is toil in this exact sense. It’s manual, it’s repetitive, it produces zero durable improvement (you have the identical argument tomorrow), and it scales with the number of mornings, forever, unless something changes the system itself. The engineering move is to spend effort once — building the redundancy, the external check, the shrunk blast radius, the recovery plan — so that individual mornings stop requiring a fresh negotiation. Most people instead re-litigate the same 6:15 AM argument roughly 250 times a year and call the cumulative exhaustion a discipline problem.

Where the analogy actually breaks

I’d rather flag this than let the framework overreach: services don’t have moods, hormones, or a nervous system, and a wake-up habit does. An SLO for a distributed system doesn’t get harder to hit because the service is sad, sick, or hasn’t slept — a person’s day-to-day capacity moves around in ways no server’s does, and a rigid error-budget mindset applied without that context turns into another stick to hit yourself with, which is precisely the failure mode this framework is supposed to replace. The honest version of this analogy treats the SLO as adjustable, the way a team would renegotiate one with stakeholders when underlying conditions changed. A week of real illness earns a legitimate, temporary renegotiation of the target — the same adjustment an SRE team would make around a planned migration.

The other place the analogy strains: production systems don’t resent being monitored. People sometimes do, and an external check that feels like surveillance rather than infrastructure will get quietly sabotaged — alarms muted, group chats muted, the “verification” gamed until it’s decorative. The systems described here, this one included, only keep working while the external check retains real teeth and not just visibility; a scoreboard nobody enforces reverts to exactly the undefined error budget this piece opened with. That’s a design constraint worth naming honestly, not a footnote to skip past.

None of this replaces sleep hygiene, a consistent bedtime, or the basic biology of why a groggy brain makes worse decisions than a rested one — those are inputs to the system this framework describes, not competing ideas. What changes when you think about it this way is where you put your limited effort. Wanting it more on any given morning stops being the deciding factor; a stated budget, redundancy across independent failure domains, a bounded blast radius, a fast recovery path, and an external check that isn’t self-reported become the actual levers.