Downtime
Monitor whether people can work, not just whether servers respond.
Meaningful availability monitoring starts with the service users need and works backward through its dependencies.
A running machine can host a broken service
A server may respond to a network check while its application cannot accept an order. A website may load while authentication fails. These are different levels of availability. Measuring only the lowest level can create a reassuring but incomplete picture.
Choose the user journeys that matter most, such as signing in, opening a schedule or submitting an order. Define a safe way to check those journeys without changing real records or exposing sensitive data. Then connect the checks to the infrastructure they depend on.
Make an alert actionable
Every urgent alert should identify the affected service, an accountable responder and a sensible first investigation step. An alert that says only 'CPU high' leaves the recipient to work out whether anyone is affected and which system deserves attention.
Use different channels for immediate failures and slower capacity concerns. Test that the notification actually reaches the right person. An accurate alert sent to an abandoned mailbox provides little operational protection.
State the measurement boundary
Record the check location, frequency and definition of success. A check from inside the office may miss a public internet problem. An occasional check can miss a short failure. Availability reporting should explain these limitations instead of presenting a percentage as complete evidence of every user's experience.
In practice
The customer portal loads, but orders fail
Illustrative scenario, not a client case study.
In a hypothetical distributor, a homepage check remains green while customers cannot submit orders. The application depends on a database connection that the homepage does not use. A server-only check therefore misses the business impact.
- The team adds a safe synthetic check for the order workflow using approved test data. It avoids charging customers, creating live shipments or leaving uncontrolled records behind.
- When the check fails, the alert names the ordering service and links the available application and database evidence. The responder can investigate the dependency instead of assuming the whole server is down.
- After recovery, the team verifies the workflow from the relevant network locations and records the outage boundary. It reviews whether the alert arrived early enough and reached the correct owner.
A check should represent the work it claims to monitor. Infrastructure health remains valuable, but it cannot replace a carefully chosen user-facing test.
What to put in place
- Identify the most important user journeys and their dependencies.
- Use safe checks that do not alter real transactions or expose sensitive data.
- Give each urgent alert an owner, context and a first investigation step.
- Document measurement frequency, locations and known coverage gaps.
The takeaway
The best availability question is whether the intended user can complete the intended task. Build the monitoring boundary around that question.