A stated uptime target like 99.9% sounds precise and rigorous, and most people quoting it haven't actually calculated what it permits: roughly 43 minutes of downtime per month, or about 8.7 hours a year. Whether that's an acceptable target depends entirely on the system it applies to and when the downtime occurs, and a single blanket target across every system in an organisation is almost always wrong for most of them.
The useful exercise is setting availability targets per system based on actual business impact rather than applying one number everywhere. A payment processing system failing for ten minutes during business hours costs real revenue and real customer trust; an internal reporting dashboard failing for the same ten minutes overnight costs nothing. Treating both the same wastes engineering effort protecting the dashboard to a standard it doesn't need, while potentially under-protecting the payment system if the blanket target happened to be lower than what it actually requires.
Planned maintenance windows are worth excluding explicitly from an availability target, and stating that exclusion clearly, because otherwise necessary maintenance work competes against the target in a way that discourages doing it — an engineer reluctant to take a system down for a needed patch because it will count against this month's uptime number is making a decision that trades long-term reliability for a short-term metric.
The number only matters if it's measured honestly and consistently, which is where a lot of internally reported availability figures quietly diverge from reality — measuring uptime from the server's perspective rather than the user's misses the cases where the server reports healthy while users genuinely cannot reach the service, through a broken load balancer or DNS issue upstream. Measuring from outside, the way a real user experiences the system, is the only version of the number worth reporting.
