Start with what users need to accomplish, define how success will be measured, and only then discuss the target and ownership. Choosing an impressive availability percentage first may produce a number that does not describe the service. Servers can respond while bookings fail; an external step can be unavailable while the homepage remains healthy. A useful objective helps the team prioritize work and decide what to do when service deteriorates.
Distinguish an indicator describing observed behavior, an internal objective for a defined window, and a contractual commitment with its own conditions and authority. This article addresses the first two. It does not offer an uptime guarantee or a LAB service-level agreement. Confirm actual operating capacity and accountable ownership before committing to coverage or response times.
Define the service through a user journey
Choose a meaningful outcome: creating a valid booking, retrieving an authorized document or completing a file upload. Do not combine unrelated journeys if high volume in one can hide failure in another. Specify where measurement starts and ends, the included users and application versions, and whether success requires an external step.
Google's SRE guidance connects service objectives to prioritization decisions, stakeholder agreement and a process for refinement. That distinction between measurement and decision is useful here; it does not require adopting Google's targets or operating model. Google: implementing SLOs.
Product Discovery & Requirements can resolve disagreements about what “successful booking” means across product, support and engineering. Connecting that definition with measurement, alerts and response guidance can sit within Observability & Reliability Engineering, subject to the agreed scope.
Write a calculation someone else can reproduce
“Success rate” is not a complete definition. Specify numerator, denominator, window, data source and exclusion rules. Does a retry count as a separate attempt or part of the original attempt? Is an invalid request an expected rejection or a service failure? How is missing telemetry handled? Missing evidence should not silently become success.
| Definition element | Decision to agree |
|---|---|
| Eligible attempt | When does it begin, and what pre-agreed exclusions apply? |
| Good outcome | Is acceptance enough, or must the final step complete? |
| Timing | Is there a user-relevant time boundary, and what supports it? |
| Window | When does measurement start, and how are periods compared? |
| Dependencies | How are external failures represented? |
| Evidence quality | How are missing data and definition changes disclosed? |
A legitimate exclusion explains the indicator's meaning. Removing every externally caused failure simply to improve the number hides the user's experience. You may show an end-to-end indicator alongside an internal-component indicator, provided the second is not presented as the first.
Hypothetical example: two meanings of booking success
Suppose an illustrative reporting window contains 1,000 eligible booking attempts. Of these, 970 complete, 20 fail at an external provider and 10 fail inside the application. End-to-end completion is 970 divided by 1,000, or 97%. These figures are invented to explain a definition. They are not LAB performance, a benchmark or a recommended customer target.
The team can analyze internal and external responsibility separately. However, removing those 20 attempts from the denominator and calling the revised result “booking reliability” changes the meaning. Users experienced failures in both categories. The product owner decides to show the complete journey first, followed by cause categories and an explicitly uncertain category where the evidence cannot identify the cause.
The discussion also reveals that earlier reporting counted initial acceptance as success before provider confirmation. The team stops directly comparing the old and new series and records the definition change. Before approving a target, it gathers a baseline under the new definition and checks that failures can be followed up.
A higher percentage cannot compensate for weak measurement. Nor should an objective assign response responsibilities to people who are unavailable or unauthorized to perform them.
Turn a breach into a decision with an owner
Identify who receives the alert, verifies user impact, decides whether to stop rollout or activate an alternative, and communicates with affected stakeholders. State coverage hours and gaps. “The team gets an alert” does not explain what happens when the usual person is away or the notification channel fails.
A deteriorating indicator may trigger investigation of a recurring cause, postponement of a risky change or prioritization of a fix. Avoid treating the number as an automatic punishment that encourages changing exclusions instead of improving service. Record the resulting decision and its review date, distinguishing operational escalation from any contractual obligation that has not been approved.
If a proposed objective depends on removing a single point of dependency or adding an alternative, bring that evidence into Cloud Architecture Design & Review. Additional infrastructure should be evaluated against both the measured problem and the team's ability to operate it.
Accept the operating model through a rehearsal
Walk through a fictional incident, then test a safe notification route where appropriate. Does the recipient know which service is affected? Can they inspect the evidence? Do they know who decides and who communicates? Record gaps as work to complete rather than treating the exercise itself as proof of readiness.
Acceptance should establish:
- An indicator reproducible from the agreed data source.
- Documented exclusions, dependencies and missing-data behavior.
- A provisional target justified by evidence and need, rather than copied from a competitor.
- An owner, authority limits, coverage hours and a backup route.
- Actions connected to deterioration, including what may not happen automatically.
- A review point after workload, journey or measurement changes.
The handover should preserve the meaning of the calculation as well as its implementation. If a new release changes which attempts qualify, someone must approve the definition change and explain its effect on comparisons. Otherwise the team may celebrate a better number that only reflects different counting.
Frequently asked questions
Is a higher objective always better?
Not without cost or consequences. Discuss user impact, current capability and required changes before approving an unrealistic target.
Can we begin without enough historical data?
Start by defining the indicator and establishing a baseline. An explicitly provisional objective may be discussed, but should not be represented as a demonstrated commitment.
Should external provider failures be excluded?
Show them in the user journey and distinguish responsibility for analysis. Exclusions must be stable and understandable, not a device for improving the headline.
What should we prepare first?
Bring a defined journey, a provisional success definition, redacted failure examples and the decision and operating owners. These support a realistic scope without implying unavailable coverage.
Reference
Google SRE: implementing SLOs, reviewed 26 October 2026. Example percentages are teaching arithmetic, not targets or guarantees.
