SRE for Startups, Part 1: Why 100% Uptime Is the Wrong Target
Where most startups get it wrong
This is the first post in a series on implementing SRE practices in small startups. The series is inspired by work I’ve been doing recently, bringing site reliability engineering principles to an early-stage organization where the team is small, the infrastructure is young, and the temptation to treat reliability as someone else’s problem is constant. I’ll be drawing heavily from Google’s SRE book – not to replicate Google’s practices at startup scale, which would be absurd, but to extract the principles that apply universally and show how to adapt them to the constraints of a small team.
The series:
- Part 1: Embracing Risk (this post)
- Part 2: SLOs and Error Budgets
- Part 3: Eliminating Toil
- Part 4: Observability and Alerting
- Part 5: Incident Management and Postmortems
- Part 6: Release Engineering and Reducing Change Friction
Most startups think about reliability wrong. They either ignore it entirely – “we’ll worry about uptime when we have customers” – or they overinvest in it, building enterprise-grade redundancy for a service that has fifty users. Both are mistakes, and both stem from the same misunderstanding: treating reliability as a binary, something you either have or don’t.
The SRE book’s most important insight isn’t about monitoring or automation or incident response. It’s Chapter 3: Embracing Risk. The idea is deceptively simple. Reliability is not a goal to be maximized. It’s a resource to be managed.
So what’s this risk budget thing, anyway
Every system has a theoretical maximum reliability. You can make a service more reliable by investing more engineering effort – better redundancy, better testing, better deployment practices. But each increment costs more than the last, and at some point the cost exceeds the value.
The SRE book frames this as a question: how unreliable can we afford to be? Not how reliable can we be – how unreliable. That reframe changes everything.
For a startup, it’s liberating. You don’t need five nines. You probably don’t need four nines. For most early-stage products, three nines – 99.9% availability, roughly 8.7 hours of downtime per year – is more than sufficient. Your users will tolerate brief outages. What they won’t tolerate is a product that doesn’t evolve.
The time and effort you save by targeting three nines instead of four nines is enormous. That’s engineering capacity you can invest in shipping features and responding to customer feedback. In a startup, velocity is survival. Reliability that comes at the cost of velocity is a bad trade. (I’ve made this trade badly more than once.)
When you’ve burned through your budget
The SRE book introduces the concept of an error budget – the amount of unreliability your service is allowed before you need to slow down and fix things. If your SLO is 99.9% availability, your error budget is 0.1%, about 43 minutes per month.
As long as you’re within your error budget, you can ship aggressively. Deploy daily. Run experiments. Take calculated risks with new infrastructure. The error budget is permission to move fast, grounded in data rather than gut feel.
When you’ve exhausted it – when real users are experiencing more unreliability than you’ve agreed is acceptable – you slow down. Stop shipping features and focus on reliability. Fix the flaky test, patch the memory leak, add the retry logic. You earn back your budget, and then you resume shipping.
Most teams either move fast and feel guilty about it, or move slowly and feel frustrated about it. The error budget gives you a principled framework for deciding how fast to move at any given time. It replaces anxiety with arithmetic.
What this looks like at a five-person team
You don’t need a formal SRE function. You need the SRE mindset.
First, define what “reliable enough” means for your stage. This is a product decision, not an engineering decision. Talk to your customers. For a developer tool, five minutes of downtime during business hours might be catastrophic. For an internal analytics dashboard, an hour of downtime on a Saturday might be invisible. The right target depends on the product, the users, and the business context.
And make the trade-off explicit. Most startups make reliability trade-offs constantly but implicitly. They skip writing tests because they’re in a hurry. They deploy without canaries because the process feels slow. None of these are inherently wrong – they might be exactly the right trade-offs given the constraints. But they should be conscious trade-offs, not default negligence.
When I’ve helped teams adopt this mindset, the most common reaction is relief. Engineers who felt guilty about cutting corners realize they were making the right call – they just didn’t have a framework for articulating it.
The hardest cultural shift: accept that some things will break. Most engineers have an instinctive aversion to outages. We take them personally. The SRE mindset reframes outages within the error budget as expected and acceptable. They’re the cost of moving fast. The only outages that should trigger concern are the ones that blow through the budget.
Where we’re headed
In the next post, I’ll get into the mechanics of SLOs and error budgets – how to define them concretely, how to measure them, and how to use them to make shipping decisions. But the foundational idea is here: reliability is a spectrum, not a binary. Your job isn’t to prevent all failures. Your job is to fail within a budget.
For a startup, this is the most important SRE principle to internalize. It gives you permission to ship. It gives you a framework for deciding when to slow down. And it reframes reliability from a drag on velocity into a tool for managing velocity.
The SRE book says it plainly: “100% is the wrong reliability target for basically everything.” For a startup, where every engineering hour matters, I’ve come to think of that as survival strategy more than philosophy.