Error budgets for tiny teams: reliability without an SRE org

Error budgets were invented inside Google, which means every article about them assumes you have a site reliability team, a dashboard wall, and a rotation of engineers who get paged at 3 a.m. I have none of those things. I run a portfolio of free, ad-funded browser tools mostly alone, and for a long time I assumed the whole discipline was a big-company sport I could safely ignore. That assumption was wrong in an expensive way: without a stated reliability target I was making the same decision — is this outage bad? should I drop everything for this bug? — from scratch, emotionally, every single time it came up.

The error budget turned out to be the one piece of SRE practice that scales down to a team of one without losing its shape. Strip away the tooling and it is just arithmetic with a decision rule attached: pick a reliability target you can actually afford, subtract it from 100%, and treat the remainder as an allowance you are permitted to spend. When the allowance is intact, you ship aggressively. When an incident eats it, you slow down and harden things. Nobody needs to be paged for that logic to work; it works in a text file.

This guide is the version I wish someone had written for operators my size. It covers what the budget idea looks like with the enterprise machinery removed, how to pick a target from what downtime actually costs you rather than from vanity, the clock-time math at small scale, the underrated skill of deciding what not to fix, incident notes that take five minutes instead of a meeting, and the signals that tell you when this lightweight version has genuinely been outgrown.

The mechanic is almost embarrassingly simple. You choose a service-level objective — say the site responds correctly 99.5% of the time over a rolling month — and the error budget is the inverse: the 0.5% of the month, about three hours and thirty-nine minutes, during which the service is allowed to be broken. The framing matters more than the number. The budget is not a confession of failure you tolerate through gritted teeth; it is unreliability you have decided, in advance and on purpose, that you are willing to spend in exchange for moving quickly.

The big-company implementation wraps that core in machinery: service-level indicators measured from real traffic, burn-rate alerts that page someone when the budget drains too fast, and policy documents that freeze feature launches when the budget hits zero. Almost none of that survives the trip down to a two-person operation, and it does not need to. What survives is the number, some honest way of measuring against it, and the decision rule — the three parts that were doing most of the work all along. Everything else is coordination overhead for organizations where the person who broke the service and the person who fixes it have never met.

The deepest thing the budget gives a small operator is permission. Chasing 100% is not noble, it is innumerate: each additional nine costs roughly ten times more than the last, and somewhere past 99.9% your users genuinely cannot tell the difference, because their own Wi-Fi fails more often than you do. A stated budget converts "some downtime is acceptable" from a guilty secret into a design parameter, and that single reframe changes how you schedule deploys, how you triage bugs, and how you sleep.

The right way to choose a target is to price your downtime honestly, and for most small products the honest number is startlingly low. My tools earn ad revenue that works out to single-digit dollars per hour at peak and cents per hour overnight. If a site earning $30 a day goes dark for a full hour, I have lost about $1.25 — and in practice less, because a visitor who wanted a background removed at a dead moment usually just comes back later. Compare that to an e-commerce checkout, where an hour of downtime during a promotion torches real orders and real trust, and it is obvious that "acceptable downtime" is a business number, not an engineering constant.

Now price the nines. Getting to 99% — about seven hours of allowed downtime a month — costs essentially nothing; any competent static host delivers it by accident. Reaching 99.5% asks for a decent platform and a free uptime monitor. The step to 99.9% is where the bill arrives: paid monitoring, redundancy you must configure and test, and above all the implicit promise that a human notices within minutes at any hour, which for a solo operator means your phone buzzes on holidays. That first nine that costs your sleep is the one to interrogate hardest. Spending $400 a month of infrastructure and attention to protect $40 a month of revenue is not rigor, it is cosplay.

I settled on 99.5% for the web shell of each tool, and I hold it loosely, because our architecture makes the number almost unfairly easy: the heavy work happens on the visitor’s own device, so "up" mostly means a CDN keeps serving static files — the same property I lean on in A go-live runbook for a serverless browser app. The genuine reliability risk for an operation like mine is not servers falling over. It is me, shipping a broken deploy at 9 p.m. and not noticing until morning, which is exactly the kind of self-inflicted incident the budget bookkeeping is designed to catch and count.

Percentages hide the stakes, so translate your candidate targets into clock time before committing to one. Over a 30-day month the ladder looks like this, and reading it as minutes rather than nines is what makes the trade-offs feel real.

Measurement can stay proportionally humble. A free uptime checker probing the homepage and one deep route every five minutes from two regions is plenty. Yes, five-minute polling can miss a ninety-second blip entirely — and at this scale that is fine, because a blip nobody measured and no user reported rounds to zero harm. False precision has a cost too: the afternoon you spend wiring up per-request telemetry for a hobby-scale audience is an afternoon of feature work gone, a trade I stopped making once I noticed I never once acted on the extra decimal places. The point of measuring, as I argued in Measuring honestly when the numbers are small, is to inform decisions you will actually take.

The bookkeeping is one note per month with a running subtraction. Mine from this spring reads: April, zero recorded minutes; May, 47 minutes from a bad deploy that shipped a broken worker bundle; June, 12 minutes from a DNS TTL mistake during a domain change. May alone would have vaporized a 99.9% budget — 43.8 minutes — and under a 99.9% regime I would have owed myself a deploy freeze in the middle of a launch week. Under 99.5%, May consumed a fifth of the allowance, I wrote the incident note, added one guardrail, and kept shipping. Same facts, radically different month, purely because the target matched the stakes.

The budget’s least advertised gift is a principled reason to leave certain bugs alone. On a tiny team every hour spent fixing something is an hour of building something taken away, and pretending otherwise is how solo projects silt up: a backlog of forty "should fix" items, none of which ever mattered enough to schedule, all of which generate ambient guilt. The error budget reframes the question from "is this a bug?" — almost everything is — to "does this threaten the reliability I have actually promised?" Most bugs do not.

My triage runs on three axes: what the failure does, how many sessions it touches, and what a fix costs. A rendering glitch in a legacy Safari version that affects roughly 0.4% of sessions and has a one-click workaround went straight to the wontfix list with a dated note explaining why. A crash in the export path that hit every user of one feature — the ONNX worker session failure I dissected in Diagnosing a silent failure: the ONNX worker-session bug that broke tool execution — was the opposite verdict: drop everything, because work-destroying failures are the one category a free tool can never amortize. The axes make those two calls in seconds; without them, both would have felt equally urgent at 11 p.m.

The critical discipline is writing the negative decisions down. I keep a WONTFIX.md with one dated line per decision — the bug, the reach estimate, the reasoning — and I skim it once a quarter to see whether reality has changed, since a browser update can turn a 0.4% bug into a 12% bug overnight. The file exists because an unrecorded "no" gets re-litigated every time the bug resurfaces in feedback, and re-deciding is more expensive than deciding. Where a known issue genuinely affects users, it also gets an honest line in Documentation, which converts a silent embarrassment into visible candor.

Postmortem culture arrives with templates: five-whys sections, contributing-factor taxonomies, action-item owners, review meetings. All of it exists to move knowledge between people, and when the person who broke it, diagnosed it, and fixed it are the same human, most of the form is theater. What a solo operator actually needs from an incident record is much smaller: enough detail that the pattern is visible six months later, captured fast enough that it actually gets captured. Ceremony is the enemy of the second requirement — every field you add to the template lowers the odds the note gets written at all.

Mine is six lines in a single running text file, written the same day, in about five minutes: the date and duration; what a user would have seen; the blast radius as a rough count or percentage; the direct cause in one honest sentence; what fixed it; and one prevention action — or, importantly, the explicit words "none, accepted," because not every incident deserves a countermeasure and pretending otherwise breeds fake action items nobody executes. Six lines is deliberately too small to procrastinate on. That is the entire design.

The compounding payoff shows up around the one-year mark, when the file becomes greppable history. Reading mine straight through last winter, the pattern was almost comic: four of my six meaningful incidents traced to deploys pushed after 8 p.m., when I was tired and unwilling to watch the dashboard afterward. No individual note revealed that; the collection did, and it bought me a rule — nothing risky ships after Thursday noon — that has held the budget green since. When the notes keep pointing at the same subsystem instead of the same habit, that is the cue for a deliberate hardening pass of the kind I documented in Reliability hardening: device lifecycle, model integrity, and honest failures.

An error budget that finishes every month untouched is not a trophy — it is a signal you are moving too cautiously. The allowance exists precisely so you can trade small, bounded amounts of reliability for speed: shipping the refactor without a week of paranoid staging, cutting over to the new pipeline on a weekday morning instead of never, deleting the legacy code path while you still remember how it works. If you never draw on the budget, you are paying for insurance and also refusing to drive the car.

In practice, spending it well is mostly scheduling. I put the riskiest change of the month early, while the allowance is full, so a surprise has maximum room to land without breaching the target. Deploys happen on weekday mornings when I will be at the desk for the next three hours, never before dinner, never before travel. A launch that could plausibly misbehave gets a calendar block right after it labeled simply "watch." None of this is sophisticated, and all of it came directly from treating the budget as a resource to allocate rather than a scold to appease.

The subtler benefit is psychological. Under an implicit 100% standard, every incident is a small shame, and shame produces exactly the wrong engineering: quiet fixes, no notes, defensive over-caution for a month afterward. Under a stated budget, an incident that lands inside the allowance is the system operating as designed — you log the six lines, you make the one improvement, and you carry no residue into the next decision. I ship more boldly now than I did when I was pretending to promise perfection, and the uptime numbers are better, not worse.

The lightweight version has a real ceiling, and it is worth knowing the signals before you hit it. The clearest one is other people’s money: the moment a customer pays you under an SLA, your downtime cost function changes shape and someone else’s lawyer helped write it. Close behind are real-time features — collaboration, live sessions, anything where an outage interrupts work in progress rather than delaying a retry — and integrations, where your failure cascades into somebody else’s system and their patience, not yours, sets the standard.

Team growth changes the math too, in a quieter way. The solo version works because one head holds the whole state: what shipped, what is fragile, what the month’s spend looks like. The day a second engineer can deploy, that shared head is gone, and the pieces of ceremony I told you to skip start earning their keep one by one — a burn-rate alert because nobody is watching for you, a written budget policy because "slow down when it feels spent" does not survive two owners, eventually a status page because users deserve one voice during an incident, not two guesses.

Adopt each piece when a concrete conversation demands it, not when a conference talk does. The progression is budget, then alerting, then policy, then rotation — and each step should be provoked by a real customer, a real teammate, or a real incident that the lighter version handled badly. Until then, the tiny version is not a compromise; it is the correctly sized tool. A one-person shop that knows its number, spends it deliberately, and writes six honest lines per incident is running a more rigorous reliability practice than most teams ten times its size that still promise, and quietly fail to deliver, perfection.