Define reliability where your users feel it

Start with a task people need to complete. That could be signing in, submitting a request or receiving a report in time to use it. Ask what a successful experience looks like and what failure prevents someone from doing. Bring the service owner and the teams supporting the journey into the same conversation.

Map the parts of the service involved, including dependencies outside the immediate team's control. This gives you a place to discuss ownership and missing evidence. A healthy component can be useful information without answering whether the whole task succeeded. The first useful output is a shared description of the journey and its boundaries.

A service level indicator, or SLI, measures an aspect of service behaviour. Choose an indicator relevant to the journey, such as successful requests, latency or data freshness. Define what counts as an eligible event and what counts as success.

Record where the observation comes from and its limits. Server measurements can miss requests that never reach the server. Discuss which failures the evidence can reveal and where coverage needs improvement. Keep the measure understandable to the people making decisions from it.

A service level objective, or SLO, sets a target for an indicator over a defined period. Agree it with the service owner, considering user needs and what the team can operate. Record the target and observation window together.

An error budget expresses the permitted shortfall against that objective. Agree how the team will respond as the service approaches or exhausts its error budget, including decisions about improvement work and releases. A working SLO needs an agreed policy; it does not automatically become a contractual service guarantee.

Decide which conditions require a prompt operational response and which can become planned work. Alerting on significant consumption of an error budget can help connect the urgency to service impact. The response should suit the service, its traffic and the people actually available to act. Repeated alerts without a useful response deserve review.

For an important alert, identify the receiving team, the first checks and the escalation route. Include enough context to start an investigation, with a playbook where appropriate. Check that responsibilities match the support arrangements you have agreed. A notification reaching an inbox does not establish that someone is available, authorised and equipped to respond.

After a significant incident, bring together the impact, timeline and contributing factors. Review how people detected the problem, obtained information and restored the service. A blameless review helps the team examine the system and the conditions around a decision. Record what was learned in a form other teams can use.

Turn the findings into specific improvements with owners and priorities. Those might involve instrumentation, a dependency, recovery steps or clearer response responsibilities. Define how the team will check that an improvement has been completed and works as intended. Review outstanding actions alongside delivery work, so the learning remains visible after the immediate pressure has passed.