Reliability and Operations
Set service objectives around user-visible behavior
Server availability alone does not describe whether customers can finish important work. Define a service objective with an observable outcome, a precise population, an evaluation window, and a decision when performance falls short.
A service can answer requests while customers still cannot complete their task. A useful service objective therefore starts with a business journey, not a server chart. Ask what customers expect to finish, how you will observe success, and which failures count. Keep the first objective narrow enough that operations and product staff can explain the same calculation.
Describe success before choosing a target
A service level indicator is the measurement you track.[10] A service level objective is the target you choose for that measurement.[10] Treat the target as an explicit operating decision, not an advertised guarantee. Describe the eligible events, successful events, and observation window in plain language before selecting a percentage.
For an order journey, successful completion might require a durable order confirmation rather than a successful page response. Agree how cancellations, invalid submissions, and dependency failures enter the calculation. Publish these definitions beside the chart so that teams do not silently use different populations.
Observe what customers can experience
Google’s monitoring guidance defines black-box monitoring as testing externally visible behavior as a user would see it.[2] Use that perspective when choosing evidence. Combine checks of the important journey with service measurements, but label what each method actually observes. A synthetic check is not a complete account of real customer experience.
Separate speed from correctness when both matter. A fast rejection is not a successful order. Segment critical journeys when a broad average could conceal a problem for a specific customer group, while avoiding groups too small to interpret responsibly.
Write a definition that survives review
Before adopting an objective, ask the team to explain these decisions without referring to dashboard implementation details.
- Name the user journey and its business owner.
- Define the eligible population and successful outcome.
- State the evaluation window and treatment of missing measurements.
- Document exclusions and the authority to change them.
- Agree which delivery decisions change when the objective is missed.
Use the objective to choose work
More demanding targets can require more engineering effort and operating cost. A weak target may leave important failures outside the discussion. Start with observed behavior and business needs, then review whether the proposed target supports sensible priorities.
When performance falls short, inspect the journey and evidence before adding features or capacity. An objective is useful only if the team knows what decision follows. Keep contractual commitments separate from internal planning targets and obtain the appropriate review before connecting them.
Hypothetical example: a booking service
In this hypothetical example, a booking team initially measures whether its home page responds. Customers instead need a confirmed reservation. The team chooses eligible reservation submissions as its population and accepted, retrievable confirmations as its success event.
It reviews slow confirmations separately and assigns product and operations representatives to approve exclusions. The resulting objective guides discussion about reliability work. No target in this example represents a promised availability level or a measured service result.
