SLO Anti-Patterns

SLO anti-patterns appear when a reliability program looks sophisticated on paper but is weak in practice. Teams may publish objectives, dashboards, and burn-rate charts, yet still fail to improve user outcomes because the indicators are badly chosen, the objectives are politically chosen, or the results never influence engineering behavior.

The most common failure is not mathematical. It is conceptual. A service-level program should represent real service quality and guide trade-offs. When it becomes a documentation exercise, the language remains while the operational value disappears.

    flowchart TD
	    A["Weak SLI/SLO design"] --> B["Misleading reliability picture"]
	    A --> C["Untrusted objectives"]
	    A --> D["No behavioral change"]
	    D --> E["Ceremonial reliability program"]

Common Failure Patterns

Several anti-patterns appear repeatedly:

• choosing indicators that are easy to measure but weakly tied to user experience
• setting objectives no one believes or can support
• defining too many SLOs for one service
• hiding exclusions and eligibility rules inside implementation details
• treating error budgets as reporting rather than policy
• creating objectives with no owner or no review cadence

1slo_failures:
2  proxy_metric_as_sli:
3    example: "CPU as primary service-quality indicator"
4  unrealistic_objective:
5    example: "99.99% target with no architectural basis"
6  too_many_objectives:
7    example: "dozens of SLOs nobody can explain"
8  no_budget_policy:
9    example: "burn chart exists but does not affect releases"

Reliability Programs Need Honesty

One of the strongest design principles is to prefer a smaller, more honest SLO set over a larger, more impressive one. Teams can improve from an honest baseline. They rarely improve from targets they quietly ignore. This is why SLO reviews should ask not only “are the numbers green?” but also:

• do these indicators still represent real user experience
• do teams believe the targets
• what decisions changed because of this data

If the answers are weak, the program needs redesign rather than more dashboards.

Design Review Question

If leadership celebrates green SLO dashboards while on-call engineers privately believe the indicators ignore the real failure modes users experience, what is the primary anti-pattern?

The stronger answer is a dishonest reliability model. The program is measuring something, but not the thing that most meaningfully represents service quality.

Quiz Time