Availability is the time a service is operating normally and usable by its customers. An uptime promise becomes meaningful when it specifies the measurement period and what happens if the service falls short. A service-level agreement (SLA) can set that minimum expectation and the customer’s recourse. section 10.1.2
Set the commitment around business need, not the largest uptime percentage you can advertise. Greater reliability can cost more, and different parts of a business may tolerate different amounts of downtime. When a third-party service supports your own offering, examine its SLA before deciding what you can credibly promise your customers. AWS EC2, for example, states a 99.99% monthly uptime commitment with a bill credit if it falls short. section 10.1.2
Turn the uptime promise into an operational plan:
- Agree on the service and support levels with sales, product and financial leadership. Include response expectations and fund any out-of-hours coverage you promise; goodwill is not a 24/7 staffing plan. section 13.2.1
- Monitor from outside the network customers depend on. Check more than whether a page loads: a test login and a low-overhead database query can reveal failures in authentication, APIs or core services. section 13.3.1
- Choose a check interval that fits the service, and make alerts useful for locating the failure. Keep the alert route independent of the network being monitored. section 13.3.1
The practical question is not only “What uptime can we promise?” but also “Can we detect a customer-visible failure, respond within our stated support terms, and deliver the promised recourse?” section 10.1.2 section 13.2.1
