The team in this story is a composite — call them Palekar Infotech, a nine-person managed-services outfit handling infrastructure support for a dozen client companies. The details are fictional; the trajectory is one we’ve watched play out, in some variation, across plenty of real support organisations. It’s the story of how an error budget turned a team that was perpetually underwater into one that could finally tell its clients — and itself — the truth about what it could deliver.
The starting point: everything is priority one
Palekar’s problem wasn’t competence. Their engineers were good. Their problem was that every one of their twelve support contracts contained some version of the phrase “ensure maximum uptime” — and maximum is not a number. In practice this meant every alert from every client carried identical, infinite weight. A disk warning on a staging box at a small client interrupted work on a database failover at their biggest one, because no document anywhere said it shouldn’t.
The on-call engineer, a sharp woman named Divya, kept a private tally for a month and brought it to the Monday meeting: 340 alerts, of which she judged 31 had genuinely needed a human that day. Nobody disputed her numbers. Nobody could act on them either — because acting would mean deciding to ignore some alerts, and no one had the authority to decide that failure, anywhere, was ever acceptable. The firm was running a zero-tolerance policy it had never actually chosen and could not actually afford.
The turn: a client asks an awkward question
The shift started, as these things often do, with a client escalation. Palekar’s largest account suffered forty minutes of degraded checkout performance, and in the review call their CTO asked a question nobody at Palekar could answer: “What response did we actually pay for?” Not what response was ideal, or intended, or hoped for. Contracted. The honest answer was that the contract promised vigilance, not outcomes, and vigilance is unmeasurable.
The founder, to his credit, treated the embarrassment as information. He’d been reading about how site reliability teams run services against explicit targets — the practice of agreeing a tolerable amount of failure upfront and managing against the remainder. The discipline had a whole training ecosystem behind it; he ended up working through the material at SRESchool, which teaches error budget practice alongside incident management and SLO strategy, and sent his two senior engineers through the foundation certification course — five days, delivered virtually, which mattered for a small firm that couldn’t lose people to travel.
The rebuild: twelve contracts become twelve numbers
What followed was six months of unglamorous renegotiation, and this is the part worth copying. For each client, Palekar proposed replacing “maximum uptime” with two or three measurable commitments. A typical conversion looked like this: the client’s public-facing API gets a 99.7 percent monthly availability target with a fifteen-minute response commitment for breaching incidents; internal tooling gets 99 percent and next-business-day; staging gets best-effort, explicitly. The gap between each target and perfection became that service’s documented failure allowance — and, crucially, the contract now said what happened when the allowance emptied: feature-support requests queue behind stabilisation work until the number recovers.
Three client reactions, roughly equal thirds. Some signed immediately, relieved that someone was finally being concrete. Some pushed for tighter numbers and discovered, via Palekar’s new rate card, that each additional nine had a price — which converted a vague entitlement into an informed purchasing decision. And a couple resisted on principle (“we pay you so nothing fails”), one of whom eventually churned. The founder’s assessment, delivered flat: “We lost our worst-margin client and our engineers’ 2 a.m. staging alerts in the same quarter. I’d take that trade again.”
What changed operationally
Alert routing got a spine. With tiers in writing, the 340-alert month became structurally impossible. Staging noise stopped paging anyone. Alerts now fired based on how fast a client’s allowance was draining, which meant a slow error-rate climb on a big account outranked a hard failure on a don’t-care system — a prioritisation Divya had been doing by instinct and guilt, now done by policy.
Toil became visible and billable. The monthly budget review exposed which clients consumed allowance through the same recurring manual fixes. Palekar started proposing automation projects against that evidence — “this failure mode has cost you 60 percent of three months’ budgets; here’s the permanent fix” — and clients funded them, because the cost was finally denominated in something they’d agreed to care about.
Postmortems stopped being apologies. A breach now triggered a short, blameless review template: what burned the budget, what systemic change repays it. Clients received these proactively. Two of them later said the postmortem quality, more than the uptime itself, was why they renewed.
The team could finally say no — and yes. When a mid-tier client asked for a risky mid-month platform migration, the answer wasn’t a mood, it was a lookup: “Your budget’s 70 percent intact; we can absorb the risk window. Same request next month if things go badly: no.” Engineers describe that sentence as the single biggest quality-of-life improvement of the whole transition.
The hard parts nobody should skip
An honest case study owes you the friction, so here it is. Month two nearly killed the initiative: an engineer let a mid-tier client’s degraded batch job ride overnight because “it’s within allowance”, and the client phoned the founder at 7 a.m. furious. Technically the engineer was right. Politically, Palekar had rolled out budgets to clients without teaching its own people the companion rule: within-allowance never means unannounced. They added a notification standard the same week — every budget-consuming event gets a brief heads-up, even when no action follows — and the complaints stopped. The allowance governs work prioritisation, not communication.
The second struggle was internal consistency. Two engineers kept treating every alert as urgent anyway, partly from habit, partly from a sense that tiering was somehow unprofessional. It took the founder publishing the weekly interrupt statistics internally — who got paged, for what tier, at what hour — before the old reflex looked as costly as it actually was. Culture followed evidence, not the other way around.
The numbers at the one-year mark
Fictional team, plausible arithmetic: pages per on-call week down by roughly four-fifths. Contract renewals up. One engineer departed during the transition — he genuinely preferred firefighting heroics, and that’s a real cost worth being honest about. The remaining eight run more client infrastructure than the original nine did, mostly because automation hours stopped losing every scheduling fight against interrupt work. And Palekar’s sales conversations changed shape: instead of promising vigilance, they now walk prospects through a sample reliability report, effectively selling an embedded reliability function on retainer — the same shape as the “SRE as a Service” model that reliability firms offer, scaled to a small shop’s means.
What to steal from Palekar
If you run or work in a support team, the transferable moves are compact. Replace every “maximum” and “ensure” in your contracts with a number a spreadsheet can check. Tier your services honestly — staging is not production, and pretending otherwise taxes your best people. Write the exhaustion consequence into the agreement so that saying no has contractual cover. Price additional nines instead of absorbing them. And invest in the vocabulary: a shared, formal grounding in reliability practice is what lets a nine-person firm hold its own in that renegotiation with a client’s CTO. The fundamentals that make this work are the same ones underpinning the core principles behind effective DevOps-driven delivery — explicit agreements, measured feedback, blameless correction — applied to the support business specifically.
And for the individual engineers: Divya’s private tally, the budget reviews, the postmortem templates — that material became the backbone of her promotion case, and it’s exactly the kind of evidence that strengthens a DevOps engineer portfolio that actually impresses hiring managers. Reliability work generates artefacts; keep yours. In a field where role titles and career paths keep multiplying, the engineer who can show a before-and-after like Palekar’s doesn’t need the perfect title. The story is the credential.
