Your reliability target is a product decision

Picture a payments team that spends two sprints hardening a service already running at 99.98% availability. The work is competent. It also delivers nothing a single customer notices, while three roadmap items slip. Ask why, and the honest answer is often the same: an incident last quarter scared everyone, and nobody had said out loud how reliable the service actually needed to be. The silence is the real problem. The team is making a delivery trade-off, reliability effort against roadmap, without anyone deciding it on purpose.

That is the pattern worth naming. Reliability is usually filed under operations, or waved at as "quality." Neither framing forces a decision. Service Level Objectives (SLOs) and error budgets do, because they turn a vague aspiration into a number you can spend. The question stops being "are we reliable?" and becomes "how much unreliability are we willing to spend this quarter to learn, release, and change?" That is a delivery-management question, and it belongs in planning, not only in the on-call rotation.

What an SLO actually commits you to

Get the vocabulary right, because that is where the sloppiness usually starts. In Google's SRE framing, a Service Level Indicator (SLI) is a carefully defined quantitative measure of some aspect of service level, such as request latency, availability, or error rate. An SLO is a target value or range for that measure: for example, 99.9% of requests succeed over a rolling 28 days. A Service Level Agreement (SLA) is the business contract with consequences attached (Jones, Wilkes, Murphy & Smith, "Service Level Objectives").

Two points from that chapter matter here. First, good SLOs measure what users care about, and a small handful of indicators is usually enough; resist the urge to instrument everything. Second, averages hide the tail. A service with a fine average latency can still be unusable for the slowest 5% of requests, which is often your largest or most valuable accounts. Availability and latency need careful aggregation, usually at percentiles, not means.

The same authors make a point about ownership that reframes the whole exercise: SRE does not usually own the SLA, because the SLA is a business and product decision. SRE's job is to help define measurable SLIs and SLOs so the business can make that decision with data and avoid missing it. Read that the other way around and it is the argument of this piece: if the target is a product decision, then product and delivery leaders, not just operators, have to be in the room when it is set.

Reliability has a price, and 100% is the wrong target

The instinct under pressure is to push reliability as high as possible. Marc Alvidrez's "Embracing Risk" chapter argues the opposite, and the argument is economic rather than moral. Extreme reliability costs money and speed. Past a certain point, more reliability produces no benefit the user can perceive. Nobody notices the difference between 99.99% and 99.999% if their own network, device, and ISP are less reliable than either, while the cost of getting there shows up directly as slower releases and diverted engineering time.

So the goal is not to maximize reliability. It is to align a service's risk with the business's tolerance for risk, and that tolerance differs by service. The consumer login path and the internal analytics exporter do not deserve the same target, and pretending they do wastes effort on one and under-protects the other. Alvidrez is explicit that product owners should be involved in translating business goals into reliability objectives. This is where "reliability is a product decision" stops being a slogan: someone who owns customer outcomes has to say how much unreliability is acceptable, because they are the ones who can weigh it against everything else the team could build instead.

The error budget is the mechanism that changes behavior

An SLO on its own is a target. What makes it operational is the error budget: the allowed unreliability, which is simply the inverse of the SLO. A 99.9% availability target over four weeks permits roughly 0.1% downtime. That remainder is a budget the team gets to spend on releases, experiments, migrations, and all the changes that carry risk.

Steven Thurgood's example error budget policy in the SRE workbook spells out the logic. The policy's stated goal is to protect customers from repeated SLO misses and to give teams an incentive to balance reliability against other features. The example enforcement rule is concrete: if a service exceeds its error budget over the preceding four-week window, the team halts changes and releases, except P0 and security fixes, until the service is back within SLO. Because the page also notes that changes are a major source of instability, the freeze targets the actual cause rather than punishing the team.

Two things about this policy are easy to miss and worth keeping. It says explicitly that halting change is undesirable. A freeze is a signal something is wrong, not a virtue. And it frames the budget as a control mechanism for diverting attention to stability when the data shows stability matters more right now than the next feature. The point is not the freeze. The point is that a burned budget changes the next planning decision automatically, without a meeting where the loudest person wins. When there is budget left, the team ships and takes risks. When it is gone, reliability work moves to the top of the backlog by prior agreement. That is delivery management encoded in a rule.

Where this connects to delivery metrics

If your organization already tracks DORA metrics, the SLO conversation plugs straight in rather than competing with it. DORA groups its five software delivery performance metrics into throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate and deployment rework rate), per DORA's "DORA's software delivery performance metrics." Reliability entered this picture deliberately: availability was added to the model in 2018, and reliability broadened the operational-performance idea in 2021, with deployment rework rate arriving in 2024 (DORA, "A history of DORA's software delivery metrics").

DORA's own warnings are the part to internalize. It cautions against setting metrics as goals in themselves, against one-metric thinking, against siloed ownership, and against measuring at the expense of actually improving. It also argues that for high performers, speed and stability are not a long-term trade-off, but only when metrics carry application and service context and ownership is shared. An error budget is one honest way to hold speed and stability in the same frame: throughput spends the budget, instability burns it faster, and the SLO tells you when the balance has tipped. Change fail rate and failed-deployment recovery time are, in practice, the levers that determine how quickly a service consumes its budget.

It is a socio-technical problem, not a dashboard

None of this works if you treat the target as purely technical. The research on continuous delivery is consistent that the constraints are as much organizational as architectural. A systematic review of 69 studies found that continuous practices do enable frequent and reliable release, but adoption depends on testing effort, team awareness and transparency, design principles, skilled and motivated people, domain, and infrastructure, and that pipelines themselves introduce security and reliability challenges (Shahin, Babar & Zhu, 2017). A follow-up mixed-methods study of practitioners across 19 organizations found that CD requires treating quality attributes such as deployability, testability, monitorability, loggability, and resilience as first-class architectural concerns, not afterthoughts (Shahin, Zahedi, Babar & Zhu, 2019).

Delivery timing is similarly social. A study of 185 teams at ING found that on-time delivery was driven largely by requirements refinement, task dependencies, organizational alignment, and organizational politics, with team familiarity and dependency structure explaining much of the schedule deviation (Kula, Greuter, van Deursen & Gousios, 2022). The lesson for reliability targets: a budget that keeps burning is often pointing at coupling, unclear requirements, or misalignment between teams, not at engineers who need to try harder.

The practice signals point the same way. Salesforce reports standardizing SLI/SLO definitions and tooling and onboarding roughly 1,200 services in the first year, with the SLO dashboard used in operational reviews to catch dips, inspect dependencies, and trigger investment conversations (Salesforce Engineering). More recent reporting describes SLOs and SLAs being democratized through federated SRE roles alongside operational and financial measures such as DORA metrics and cost per change (InfoQ, 2026). The common thread is that SLOs earn their keep as a shared language for decisions, not as a scoreboard.

Monday morning: five questions about one service

Pick one real service and ask these before touching a dashboard.

1. Who is the user, and what do they actually feel when this service degrades? If you can't name the failure the user experiences, you can't pick a meaningful SLI.
2. What is the target, and who agreed to it? If no product or delivery owner has signed off on the number, you have an operations metric, not a product decision.
3. What does the budget look like right now, and what have we been spending it on? Releases, migrations, and incidents all draw down the same account.
4. What happens automatically when the budget is gone? If the answer is "we discuss it," write the rule down instead: a four-week window and an agreed action.
5. If the budget kept burning, what would we look at first? Coupling, refinement, or an unrealistic target are more likely culprits than effort.

What SLOs do not do

Be honest about the limits. An SLO does not replace product judgment about what to build, and it will not tell you whether a feature is worth having. It does not substitute for usability research. A service can hit every target and still frustrate users. It says nothing about security and compliance obligations, which are floors you meet regardless of budget. And it is not a replacement for genuine incident learning; a met SLO can still hide a near-miss worth understanding.

The sharpest failure mode is using SLOs to rank teams. The moment a budget becomes a KPI that reflects on individuals, people optimize the number instead of the service: targets get set low to look safe, or misses get hidden. DORA's warning against measuring at the expense of improving applies exactly here. An error budget is a tool for making a trade-off visible, not for grading the people making it.

The decision to change

So the move is small and specific. In your next planning or release conversation, take one service, say out loud how much unreliability you are willing to spend and why, tie it to a user-visible effect, and agree in advance what changes when the budget runs out. That last part is the whole point: a reliability target that does not alter the next decision is just a number on a wall. The question to leave the room with is not "are we reliable enough?" but "what will we stop doing when we have spent too much?" Have that answer before you need it.

Sources

• Alvidrez, M. (2016). Embracing risk. In B. Beyer, C. Jones, J. Petoff, & N. R. Murphy (Eds.), Site reliability engineering: How Google runs production systems. O'Reilly Media. sre.google/sre-book/embracing-risk
• Harvey, N. (2026, January 5). DORA's software delivery performance metrics. DORA. dora.dev/guides/dora-metrics
• Harvey, N. (2026, January 2). A history of DORA's software delivery metrics. DORA. dora.dev/insights/dora-metrics-history
• Jones, C., Wilkes, J., Murphy, N., & Smith, C. (2016). Service level objectives. In B. Beyer, C. Jones, J. Petoff, & N. R. Murphy (Eds.), Site reliability engineering: How Google runs production systems. O'Reilly Media. sre.google/sre-book/service-level-objectives
• Kula, E., Greuter, E., van Deursen, A., & Gousios, G. (2022). Factors affecting on-time delivery in large-scale agile software development. IEEE Transactions on Software Engineering, 48(9), 3573–3592. doi.org/10.1109/TSE.2021.3101192
• Linders, B. (2026, June 4). How a culture of data-driven conversations can support platform engineering. InfoQ. infoq.com/news/2026/06/data-driven-platform-engineering
• Shahin, M., Babar, M. A., & Zhu, L. (2017). Continuous integration, delivery and deployment: A systematic review on approaches, tools, challenges and practices. IEEE Access, 5, 3909–3943. doi.org/10.1109/ACCESS.2017.2685629
• Shahin, M., Zahedi, M., Babar, M. A., & Zhu, L. (2019). An empirical study of architecting for continuous delivery and deployment. Empirical Software Engineering, 24(3), 1061–1108. doi.org/10.1007/s10664-018-9651-4
• Sheth, T. (2022, April 5). Transforming service reliability through an SLOs-driven culture & platform. Salesforce Engineering Blog. engineering.salesforce.com
• Thurgood, S. (2018). Example error budget policy. In B. Beyer, N. R. Murphy, D. K. Rensin, K. Kawahara, & S. Thorne (Eds.), The site reliability workbook (Appendix B). O'Reilly Media. sre.google/workbook/error-budget-policy