There's a particular kind of meeting that happens at most engineering organizations, usually sometime in Q1 or after a bad incident. Someone pulls up a blank doc, types "Service Level Objectives," and the room starts negotiating. By the end of an hour, you have numbers. Four nines for the payment service. 99.5% for the recommendation engine. 200ms p99 latency for the API gateway. Everyone nods. The doc gets committed to a wiki page that will be visited exactly twice more: once when someone links it in a postmortem, and once when a new engineer asks where the SLOs live.
Six months later, the system is violating those SLOs regularly, nobody is getting paged about it, and the team has quietly stopped looking at the error budget dashboard. The SLOs are technically in place. They're just not doing anything.
This is the gap that most SLO implementations fall into — not because the concept is wrong, but because the numbers were chosen in the wrong room, by the wrong process, for the wrong reasons.
SLOs Chosen for Comfort Will Optimize for Comfort
The conference room SLO problem has a predictable shape. Teams set targets based on what sounds reasonable, what they think they can hit, or what a vendor template suggested. The number has no relationship to what users actually experience as degraded service. It has no relationship to the failure modes the system actually exhibits under load. It's a number that felt defensible in a meeting.
The tell is when an SLO is set comfortably above current performance. If your service is running at 99.7% availability and you set an SLO of 99.5%, you've created a metric that will never fire, never generate error budget burn, and never force a conversation. You've built a dashboard that tells you everything is fine by design. That's not an SLO — it's a comfort blanket with a percentage sign.
The opposite failure is equally common: aspirational SLOs set at four nines because that's what "serious" services have, without any analysis of whether the underlying infrastructure, deployment practices, or dependency chain can actually support that target. These SLOs fire constantly, generate alert fatigue, and get quietly ignored. The team learns that the SLO number is fiction, and they stop trusting the signal.
Both failures share a root cause: the target was chosen without asking what user experience the number is supposed to protect.
The Question That Changes the Process
The SLO conversation changes when you anchor it to a specific user-visible failure. Not "what availability percentage sounds right" but "what does a user experience when this service is degraded, and at what point does that experience become unacceptable?"
This reframes the work. For a payment service, the question becomes: at what error rate do transactions start failing in ways users notice and complain about? For a recommendation engine, it might be: at what latency does the page feel slow enough that users abandon it? These aren't hypothetical — they're questions you can answer with user behavior data, support ticket patterns, and session analytics. The SLO target should be derived from that answer, not from a round number that felt right.
The latency dimension is where this discipline matters most. P99 latency targets are almost universally set without examining the actual distribution of request latency under production load. A 200ms p99 target sounds reasonable until you look at your actual latency histogram and discover that your p95 is already at 180ms during peak traffic, which means your p99 is regularly at 400ms, which means you're violating the SLO constantly and nobody noticed because the dashboard was built to show the average.
Error Budgets Only Work If You Spend Them
The other half of the SLO failure pattern is the error budget that nobody touches. Error budgets are supposed to create a forcing function: when you're burning budget fast, you slow down deployments and focus on reliability work. When you have budget to spare, you move faster. In practice, most teams treat the error budget as a scoreboard rather than a decision input.
The reason is usually organizational. Error budget burn requires someone with authority to say "we're slowing down releases this sprint because our reliability work isn't keeping up." That conversation is uncomfortable. It requires the SLO to be taken seriously as a constraint, not just a metric. And it requires the team to have agreed in advance — before the budget starts burning — what the response will be when it does.
Teams that skip this agreement end up in a familiar place: the error budget is red, the releases continue, and the SLO number becomes background noise. The system has learned that the SLO has no teeth.
The fix is less technical than it sounds. Write down, in the same document as the SLO target, what the team will actually do when error budget burn hits specific thresholds. Make it a policy, not a suggestion. Then test whether that policy survives contact with a real incident and a real release deadline.
If it doesn't, you've learned something important about whether your organization is actually ready to use SLOs as a reliability tool — or whether you're just using them as conference room decoration.