Site Reliability Engineering was invented at Google, where teams have the headcount to have dedicated SREs, toil-reduction programmes, and extensive capacity planning functions. Most companies don't. That doesn't make the principles inapplicable — it means the implementation needs to be lighter.
We run production for teams with a handful of engineers, nobody with “reliability” in their job title, and a roadmap that does not slow down for anyone. What follows is what we actually install in those teams, in the order we install it. None of it needs a hire, a tool purchase, or a reorganisation.
SLOs: pick two metrics and measure them honestly
Don't start with a comprehensive SLO programme. Start with two metrics that matter to your users: probably availability and latency at a meaningful percentile (p95 or p99, not p50). Define what "good" looks like. Measure it. Make it visible. That's it for now.
The value of an SLO isn't the number. It's the discipline of having agreed, in advance, what good looks like — so that when something degrades, you have a shared language for how bad it is.
Why the percentile matters
A p50 latency of 200ms tells you the median user is fine. It tells you nothing about the slowest five percent, and the slowest five percent are the ones who open support tickets and churn. The tail is where the database lock, the cold cache and the retry storm live. Measure p95 at minimum. If you have the traffic to make p99 statistically stable, use that.
What “honestly” means
Measure at the edge, as close to the user as you can — the load balancer or the CDN, not the application’s own health endpoint. A service that reports itself healthy while every request behind it times out is the most common way we see teams fool themselves.
Define availability as the ratio of good requests to total requests, not as “the instance was up”. An instance can be up for a month while returning 500s for an hour of it. Decide what counts as a bad request (5xx, and anything slower than your latency threshold, is a sensible default) and write the definition down next to the number.
Then put the two numbers on a dashboard that people actually look at. If your team lives in Slack, post them there daily. Visibility is the whole mechanism. An SLO nobody sees is a config file.
Error budgets as release gates
The practical version for small teams: if your availability SLO is 99.5% and you've used 80% of your error budget this month, that's a signal to slow down feature work and focus on reliability. You don't need a formal process — you need one person to own the number and the authority to slow down releases when it's trending badly.
The arithmetic
99.5% over a 30-day month means you can be unavailable for 0.5% of 720 hours — about three hours and thirty-six minutes. That is your budget. Two twenty-minute incidents and a bad deploy that took an hour to roll back have used well over half of it. Framed that way, the number stops being abstract and starts being a resource the team is spending.
Most teams are surprised by how much of the budget goes on planned work: migrations, schema changes, a deploy that needed a restart. That is fine. The budget exists to be spent. What it prevents is spending it all in week one and having no room for the unexpected.
What slowing down actually means
It is not a freeze. A freeze punishes the whole team for one system’s fragility and pushes risk into a bigger, scarier release later. Slowing down looks like: smaller changes, no deploys on the day before a weekend, the reliability tickets that have been sitting in the backlog move to the top, and any change touching the component that burned the budget gets a second pair of eyes.
The person who owns the number needs real authority, and that has to be agreed by whoever runs the product side before the first bad month, not during it. If the owner can be overruled by “but this feature is promised to a customer”, the budget is decorative.
Blameless postmortems, lightweight version
For every incident that causes user impact: write down what happened, what the timeline was, what the contributing factors were, and what would prevent recurrence. No names in the contributing factors section — only systems, processes, and decisions. Share it with the team. This is the entire practice, stripped to its core.
"A blameless postmortem is not about making people feel better. It's about making the system better."
The one-page template
- Summary. Two sentences. What broke, for whom, for how long.
- Timeline. Timestamps from first symptom to full recovery, including when a human first noticed. The gap between “it started” and “we noticed” is usually the most useful number in the document.
- Contributing factors. “The deploy pipeline has no canary stage”, not “Sam deployed without checking”. If a person made a reasonable decision with the information the system gave them, the system is the factor.
- What would prevent recurrence. Concrete, owned, dated. One or two items, not twelve. Twelve actions means none of them get done.
Write it within two working days while memory is fresh. Keep the documents somewhere searchable. After six months you will have a folder that tells you, better than any monitoring tool, where your real weak points are — because the same contributing factor will appear three times.
Why blameless is a practical rule, not a kind one
The moment a postmortem names a person, the next incident’s timeline gets vaguer. People stop saying “I ran the migration at 14:02” and start saying “the migration was run”. You lose the detail you need to fix anything. Blamelessness is how you keep the data honest.
What to leave out for now
Toil measurement, formal capacity planning, production readiness reviews and a rotated on-call with paging tiers are all genuinely useful. They are also things a five-person team does not have the surface area to justify yet. Add them when a specific pain point demands it — when someone is spending a day a week on manual restarts, measure toil; when you have had two capacity-related outages, plan capacity.
The full SRE book is worth reading. Apply it selectively, starting with the parts that address your most frequent pain points.
Where to start this month
- Pick availability and p95 latency for your single most important user-facing path. Write the definitions down.
- Get both numbers onto a dashboard measured from the edge. Post them daily wherever the team already talks.
- Name one person as error budget owner and agree, in writing, what they are allowed to slow down.
- Copy the one-page template into your wiki. Use it on the very next incident, however small.
That is the whole first iteration. It will feel thin. It is meant to. Run it for a quarter and the next thing you need will be obvious — and it will be a thing you need, rather than a thing Google needed.