← Back to news 01.08.2026

99.9 percent of what?

An availability figure without a definition is an opinion. What counts as an outage, whether an HTTP 200 proves anything at all, and how maintenance windows enter the calculation shape the number more than the technology behind it.

Few commitments are given as readily as availability. 99.9 percent appears in proposals, contracts and on status pages. The interesting question is rarely asked: 99.9 percent of what, measured how, and who defined what counts as an outage?

Two states are not enough

Reachable or not reachable does not describe operations. An application that still answers but takes eight seconds is down as far as users are concerned, and counts as available in the statistics. Conversely, a single failed request is not an outage: alerting on the first timeout breeds alert fatigue, and that costs you the incident that was real. So you need a state of its own for slow and a threshold of consecutive failures, and both belong to the definition.

What 99.9 percent means in hours

Germany's BSI publishes a classification that translates percent into time: six availability classes, VK 0 to VK 5.

Availability classes per BSI, HV-Kompendium Band G, table 3. Downtimes apply to 7 x 24 hour operation.
ClassDesignationMinimum availabilityDowntime per monthDowntime per year
VK 0No assured availability
VK 1Normal availability99.0 %under 8 hunder 88 h
VK 2Increased availability99.9 %under 44 minunder 9 h
VK 3High availability99.99 %under 5 minunder 53 min
VK 4Highest availability99.999 %under 26 sunder 6 min
VK 5Availability even under force majeure (disaster tolerant)

That places the figure from the headline. 99.9 percent is VK 2, increased rather than high availability, allowing just under nine hours of downtime per year. Whoever means high availability means VK 3, and therefore 53 minutes. Note also that VK 0 is a class of its own: no assured availability. Most systems effectively sit there, it is just rarely written down.

Two caveats belong with this. The times apply to 7 x 24 hour operation, so with different service hours the same percentage means an entirely different number of hours. And the HV-Kompendium has been withdrawn; the BSI continues to publish the foundational volume for information purposes because its content remains fundamental and applicable. The classification is established practice, not a requirement, and the boundaries are fluid.

HTTP 200 is not proof of health

An error page also answers with 200. So does a login screen with the database gone behind it. Checking only the status code measures the web server, not the application. It becomes meaningful with an expected keyword, a forbidden one for error pages, or a value at a specific place in the JSON response. And whatever never answers at all is invisible to a monitor anyway: a nightly job that does not run produces no failed request, it produces nothing. That needs the opposite direction, where the job checks in and the missing check-in is the outage.

Maintenance windows are the point of dispute

The footnote of the BSI table leads to the most uncomfortable point: does planned downtime count against the promise? If the contract does not say, it will be argued about the moment it gets expensive. The only clean approach is a measurement that counts maintenance separately.

Monitoring is itself a tool

The part that tends to be overlooked: whoever may query arbitrary addresses can sweep the internal network with it. Monitoring with free URL entry is a port scanner with permission. That is why every check should be preceded by a comparison of the target against private and reserved address ranges.

How isidaten measures

Four check types: HTTP, TCP, ping and heartbeat. Four states instead of two, with a dedicated slow threshold and a configurable number of consecutive failures. Content is verified via expected and forbidden keywords and a JSON path with a target value. Response times split by DNS, connection, first byte and total, because slow is not a diagnosis. Plus certificate lifetimes, downtimes with cause and maintenance flag, daily statistics that count maintenance checks separately, and the SSRF check before every probe. Outage, recovery and expiring certificates trigger rule chains, so what follows is an action with an owner rather than an email.

And what of it goes public

A status page that only ever shows green is marketing. What makes it credible is the history. Incident reports therefore run through the chain of investigating, identified, monitoring, resolved, with a timestamp per step, can be attached to the measured downtime instead of being written freely, and published on the trust center. That publishing is a permission of its own is deliberate: whoever handles an incident does not thereby decide what goes public.

More on the module page. Why the commitment itself belongs in the contract, with service hours and escalation, was covered here recently.

Questions about this update?

Talk to us – we are happy to show you this feature in a demo.