Site reliability engineering
Reliability you can put a number on.
“It feels slow” is not an engineering target. We give your service measurable objectives, the observability to prove whether you are meeting them, and an incident process that does not depend on one person being awake.
Capabilities
What we cover
- SLIs, SLOs and error budgets Service objectives derived from what your users actually experience, with error budgets that turn “should we ship or stabilise?” into a decision the data makes for you.
- Observability Metrics, logs and traces that answer real questions — Prometheus, Grafana, OpenTelemetry — instead of dashboards nobody opens during an incident.
- Alerting that earns the page Alerts tied to symptoms and budget burn rather than raw thresholds, so on-call gets woken for things that matter and sleeps through the rest.
- Incident response and on-call Escalation paths, severity definitions, comms templates and a rota that is humane, plus blameless post-incident reviews that actually produce fixes.
- Production readiness Reviews before launch: failure modes, dependencies, limits, rollback plans and the operational questions that are painful to answer after go-live.
- Capacity and performance Load modelling, headroom analysis and cost-aware scaling, so growth is planned rather than discovered during a traffic spike.
- Toil reduction Measuring where operational time actually goes, then removing the repetitive work with automation instead of hiring around it.
- Resilience testing and DR Failover exercises, dependency failure drills and restore rehearsals with the timings recorded, because an untested recovery plan is a hypothesis.
Engagements
How this usually starts
- Reliability review. A short assessment of what breaks, how you find out, how long recovery takes, and where the biggest gap between expectation and reality sits.
- SLO workshop. Defining objectives with the people who own the service, and instrumenting them so they are measured rather than asserted.
- Fractional SRE. Ongoing reliability capacity for teams that need the practice but not yet a full-time hire — the discipline without the headcount.
- Incident readiness. Building the on-call rota, runbooks and escalation process before the outage that makes you wish you had.
Choosing a target
How much reliability do you actually need?
“Five nines” sounds like an ambition until you price it. Each extra nine roughly multiplies the engineering and on-call cost, so the target should be a commercial decision rather than a reflex.
| Target | Downtime per 30 days | What it usually implies |
|---|---|---|
| 99% | 7 hours 12 minutes | Office-hours support is enough. Fine for internal tools. |
| 99.9% | 43 minutes | Monitoring and a defined on-call rota. Where most business services should sit. |
| 99.95% | 21 minutes | Redundancy at every tier, automated failover, rehearsed recovery. |
| 99.99% | 4 minutes | Multi-region, no single points of failure, and a team funded to keep it that way. |
Four minutes a month leaves no room to notice an incident, let alone join a call and diagnose it. At that point recovery has to be automatic, which is an architectural commitment rather than an operational one.
Common questions
Questions we are usually asked first
What is the difference between an SLI, an SLO and an SLA?
An SLI is the measurement — the actual availability, latency or error rate your service delivered. An SLO is the internal target you hold yourselves to. An SLA is a contractual promise to a customer with financial consequences attached.
A useful test: if missing it means you reprioritise engineering work, it is an SLO. If missing it means you owe someone money, it is an SLA. Your SLO should always be stricter than your SLA, so you find out before your customer does.
What is an error budget?
The amount of unreliability your SLO permits. At 99.9% over 30 days, the budget is roughly 43 minutes. While budget remains, the team ships; when it is exhausted, effort shifts to reliability until it recovers.
The value is not the arithmetic. It is that “ship or stabilise?” stops being an argument between engineering and product and becomes a number both of them already agreed on.
How is SRE different from DevOps?
DevOps is largely about how software gets built and released — shortening the path from commit to production. SRE is largely about what happens once it is there — defining what reliable means, measuring it, and deciding what to do when it slips.
In a small organisation the same engineers do both, and the distinction matters less than making sure neither is neglected. We cover both.
Do we need a full-time SRE?
Usually not at first. What most teams need is the practice established — objectives defined, observability instrumented, alerts made meaningful, an on-call process written down — and then maintained by the existing team.
That is what fractional SRE is for: the discipline without the headcount, until reliability work is genuinely a full-time job.
We already have dashboards. Is that observability?
Not necessarily. Dashboards show what someone anticipated needing. Observability is being able to answer a question you had not thought of during an incident, without shipping new code to find out.
The practical test is whether, at 3am, the data can tell you which dependency is slow and for which subset of users. If it cannot, you have monitoring rather than observability.
Our on-call is burning people out. Where do we start?
Almost always with alert quality. Count how many pages in the last month required action, and how many were noise. If the ratio is poor, fix that before touching the rota — a fairer schedule for alerts that should never have fired solves nothing.
Reliability is a product decision
Perfect uptime is not a goal worth paying for, and neither is treating every outage as a surprise. The useful question is how reliable this particular service needs to be, what that costs, and whether you are currently over- or under-investing. We help you answer that in numbers, then build the practice that keeps it honest.