Define the service
A successful ping is not always a successful service.
Availability depends on the promised function and the observer's location. A server may accept a connection while an application cannot authenticate, fetch data, or complete a useful request.
Measure success and failure over a defined window, record the affected scope, and distinguish a complete outage from a partial outage. A single probe can miss regional, client-specific, or intermittent failures.
Make the result useful
Availability is a ratio with a purpose.
Count comparable operations in a defined window: successful operations divided by the total valid operations. A timeout, rejected request, or incomplete user journey counts as a failure when the service promise says it should have succeeded.
The remaining failure allowance is an error budget. When failures consume too much of it, teams can pause risky changes and focus on reliability work; when the budget is healthy, they can make measured improvements. The threshold must be tied to user impact, not chosen only because it is easy to calculate.
Build the model
Four availability questions
Function
What user-visible operation must complete successfully?
Window
Which time interval turns responses into a comparable measurement?
Scope
Which regions, clients, paths, or features are affected?
Recovery
When did the service return and how was recovery verified?
Mini investigation
Inspect an availability result
Select the observed result and identify the most direct interpretation.
The intended user-visible check completed within the accepted time and returned the expected result.
Record the success with its location, timing, and check version.
Knowledge check
Test your availability model
Answer eight questions. The answer order changes each time.