Engagement at a glance
- Client profile: Series A HR-tech SaaS, US; 2–3 major incidents per month; enterprise renewals at risk.
- Shape: 12-week SRE program bootstrap, converted to a managed SRE retainer at the client's request.
- Result: 99.98% uptime the following quarter (from 97.1%); MTTR 84→11 minutes; two at-risk enterprise renewals closed.
- Human result: zero out-of-hours pages for the lead engineer after week 9.
The situation: reliability was eating the renewal pipeline
97.1% uptime sounds close to fine until you do the arithmetic: it's more than 21 hours of downtime a quarter, and for a system HR teams use to run payroll cycles and onboarding, those hours land during business days. Two enterprise customers had already put reliability language into renewal negotiations. There were no SLOs, no error budgets, no postmortem discipline — and on-call was one informal rotation of one: the lead engineer, whose phone was the alerting system of record.
This is the standard shape of the problem we describe in SRE for SaaS: reliability debt doesn't show up as an engineering metric first, it shows up in the renewal pipeline. The engagement was scoped accordingly — not "install observability," but "make reliability a number the CEO can put in a renewal conversation."
What we did, phase by phase
The unglamorous part did the most work: replacing cause-based threshold alerts ("CPU > 80%") with symptom-based burn-rate alerts collapsed page volume enough that the pages that remained meant something. That mechanism — and why 44% of outages start with a dismissed alert — is unpacked in our alert fatigue teardown and the golden signals guide.
What the alert rewrite actually looks like
Before: "CPU above 80% on app-server-3" pages a human at 2 a.m. It says nothing about whether a user is affected, it fires during every deploy and every batch job, and after the fifth false alarm the on-call engineer's thumb learns the dismiss gesture. After: "the login journey is burning its 30-day error budget at a rate that exhausts it in six hours" pages a human — and that sentence contains its own justification. A slow-burn companion alert ("budget exhausted in three days at current rate") opens a ticket instead of paging, which is the difference between an alerting system and an insomnia system. In a rewrite of this shape, most cause-based alerts don't get converted — they get deleted, and nobody misses them, because the four journey SLOs cover what all two hundred thresholds were pretending to.
The error-budget policy earned its keep mid-engagement, the way it always does: a feature release wanted to ship while a journey's budget was nearly spent, and for the first time the conversation wasn't a negotiation between the loudest engineer and the most anxious PM. The policy leadership had signed in week 2 answered it: reliability work first, release when the budget recovers. One deferred release bought the credibility that makes every later trade-off discussion short. An error-budget policy that has never delayed anything is, as we tell clients up front, a dashboard cosplaying as a policy.
The handover test was equally specific: by the fifth live incident, the client's engineers ran detection-to-postmortem alone while we watched the clock and said nothing. That's the artifact that makes a bootstrap a bootstrap — the practice survives the consultants leaving. The retainer that followed covers the 24×7 pager and quarterly SLO reviews, not dependency: their team still runs their own incidents.
The results, next quarter
- 99.98% uptime over the following quarter, from 97.1% — about 13 minutes of downtime against the previous quarter's 21+ hours
- MTTR down from 84 minutes to 11 — runbooks plus alerts that identify the failing journey instead of the noisy host
- Zero out-of-hours pages for the lead engineer, whose informal rotation-of-one was retired in week 9
- Two enterprise renewals saved — the uptime number and the postmortem discipline went directly into both renewal conversations
Engagement type: Project Delivery · 12 weeks · converted afterward to a Managed SRE retainer with a 15-minute acknowledgement SLA. What each nine of uptime actually budgets you is on the SLA calculator; the questions that would have exposed this problem a year earlier are in how to choose an SRE consultancy.
A note on this write-up: this is a representative engagement — the phases, artifacts and outcome metrics are exactly how InfraZen runs an SRE bootstrap, published this way while client-cleared named case studies are prepared. The mechanics above are the part you can hold us to in a first call.
Related: SRE consulting services · SRE for SaaS · What is SRE? · Next case: 47 services to EKS, zero downtime