Defining availability requirements for a business workload

An availability requirement should name a business action that must succeed, for whom, and over which period. It should also state how success will be measured. A server or cloud service target is useful operational information, but users experience the whole path through an application and its dependencies.

Start with the journey

Ask the business owner which actions can stop work or harm customers when unavailable. Separate essential actions from those that may be delayed. For an online shop, placing an order may need a different target from viewing an older sales report. The distinction is illustrative; the owner must decide what matters for the actual workload.

For each journey, write down the users, expected operating hours and acceptable degraded behaviour. Decide whether a slow or incorrect response counts as unavailable. A page that loads while its payment action fails should not count as an available checkout journey.

Turn the requirement into a measure

Choose a service level indicator (SLI) that reflects the journey. It might be the share of valid order attempts that complete successfully, measured at the application boundary or from a representative user location. Specify the denominator, exclusions and measurement window. Otherwise, two teams may report different availability figures for the same incident.

Set a service level objective (SLO) for that indicator with the business owner. An SLO is an internal target for workload behaviour.

A service level agreement (SLA) is a commitment with consequences under its terms. A cloud provider's SLA covers the specified provider service and conditions, not automatically the end-to-end business journey. Review those terms when assessing dependencies, but do not substitute them for the workload requirement.

Check that the target is achievable in normal operations and during expected maintenance and faults. The objective should guide design and response priorities, rather than merely repeat a number from a vendor page. Record who owns measurement and what happens when the target is missed.

Key Availability Metrics and Targets

Define recovery beside availability

Availability over a measurement period does not tell the team how quickly one incident must end or how much recent data it can lose. Specify recovery time objective (RTO) and recovery point objective (RPO) separately. Ask how the impact changes as an interruption lengthens and which transactions could be recreated if lost.

Dependencies must be included. If the journey requires an identity provider, payment service or database, its effective recovery cannot be faster than the critical path allows unless a workable alternative exists. Record any accepted reduced mode, such as collecting requests for later processing, and test that it really supports the business action.

A useful requirement record has the journey, owner, hours, success measure, SLO, RTO, RPO, dependencies and date of agreement. Revisit it when usage, integrations or business priorities change. The result is a specific design input that can be monitored and tested.