Define the journey before the percentage
Consider an order that moves through sign-in, payment and confirmation. If the confirmation never arrives, a healthy home page does not describe the user's experience. Define the start and end of the journey and count failed attempts consistently. State the reporting window and any agreed exclusions beside the target.
Review the places failure can spread
Follow the dependencies behind that journey. A slow external response, exhausted connection pool or delayed background job can affect the result. Decide where a timeout, queue or degraded mode would protect the rest of the system. More components also mean more configuration to operate and test.
Rehearse restoration
Choose a safe test of one important failure. Check who receives the alert, which information they need and how service is verified after recovery. Record the gap between the written plan and the actual exercise. The result should be a specific improvement with an owner, rather than a general statement that recovery worked.
Further reading from the original publisher: Microsoft: reliability guidance ↗