AI Knowledge Hub

How should Product and Engineering set service level objectives for a product?

Quick answer

Set a service level objective (SLO) for a product by choosing a user journey, defining a measurable service level indicator, and agreeing a target over a stated period. Product brings evidence of the impact on users and priorities; Engineering tests whether the measure is observable and the target is achievable. Revisit the objective when user needs or the service change.

What to remember

Key takeaways

Measure an outcome that reflects a user journey, rather than infrastructure health alone.
Define the population, success condition and measurement window.
Use the target to guide reliability investment and release decisions.
Review missing data and changing usage before treating a breach as a simple score.

A product can show green infrastructure dashboards while users still fail to complete a booking or payment. Teams need a shared way to describe acceptable reliability in terms of the service people use. An SLO gives Product and Engineering a decision point when new work competes with reliability work.

Choose the journey and the indicator

A service level indicator (SLI) is a measure of service behaviour. Start with a critical journey such as completing a payment. Specify what counts as an eligible attempt, what counts as success, where the observation is made and how delayed or duplicate events are handled. Measure at a point that represents the user experience. A server uptime measure may still help diagnosis, but it cannot alone establish that users completed the journey.

Set a useful target

Established monitoring reports availability, latency and errors; an SLO turns a selected measure into a target over a period. Choose the target using user expectations, observed performance, business consequences and the engineering cost of improvement. Document exclusions and periods of low traffic. Product should explain the consequence of failure; Engineering should expose measurement gaps and feasibility. An SLO is an internal decision aid. A service level agreement is a separate contractual commitment.

Use the objective in product decisions

Review both the trend and the incidents behind it. If the objective is missed, investigate what users experienced and decide whether to invest in resilience, change release pace or revise the target with evidence. An error budget can express the tolerated amount of failure implied by the target, but it is useful only when the team agrees in advance what decisions it will inform. AI can help summarise incident themes; the team must verify evidence and retain ownership of the trade-off.

Keep the measure credible

Assign owners for instrumentation, the target and review cadence. Test the event or probe, check missing and biased samples, and segment journeys where one group experiences a materially different service. Avoid averages that conceal failures in a critical step. Reassess targets when architecture, usage or product promises change. Escalate contractual or regulated commitments separately for specialist review.

Example

Hypothetically, a subscription product measures successful account renewals from request to confirmation. Product identifies renewal failure as a serious customer problem. Engineering instruments complete attempts and checks whether third-party payment outages appear in the measure. The team agrees an initial target from observed performance and reviews failures monthly before deciding whether to prioritise resilience work.

FAQs

Is an SLO the same as an SLA?

No. An SLO is a target used to manage a service; an SLA is a contractual commitment with its own terms and consequences.
Should every feature have its own SLO?

No. Begin with journeys where failure matters and where a reliable indicator can be measured.
Does meeting an SLO prove the product is good?

No. It addresses a defined aspect of reliability; user value, accessibility and other outcomes need separate evidence.