{"id":22922,"date":"2026-08-30T09:41:14","date_gmt":"2026-08-30T07:41:14","guid":{"rendered":"https:\/\/www.curiaweb.ch\/?post_type=docs&p=22922"},"modified":"2026-08-30T09:41:15","modified_gmt":"2026-08-30T07:41:15","password":"","slug":"uptime-availability-999-percent","status":"publish","type":"docs","link":"https:\/\/www.curiaweb.ch\/en\/hilfe\/seo-monitoring\/uptime-verfuegbarkeit-999-prozent\/","title":{"rendered":"Uptime and Availability: What 99.9 % Really Means"},"content":{"rendered":"

In web hosting, cloud services, and other online services, you frequently encounter specifications such as 99.9 % Availability<\/code>, 99.95% % Uptime<\/code> or even 99,99 %<\/code>.<\/p>\n\n\n\n

At first glance, these values appear almost identical. Mathematically speaking, however, even a few decimal places can make a significant difference in the potential downtime.<\/p>\n\n\n\n

At the same time, a percentage alone does not reveal how it was measured, which time period is considered, and which events are included in the calculation.<\/p>\n\n\n\n

In this article, we explain what uptime and availability mean, how the percentages are calculated, and why measured uptime, advertised availability, and a contractual Service Level Agreement are not automatically the same thing.<\/p>\n\n\n\n

\n

Briefly explained:<\/strong> Availability of 99,9 %<\/code> This does not mean that a service must never go down. Mathematically, it means that, within the period under consideration, the service is available 99.9 % of the time and unavailable 0.1 % of the time\u2014provided that this exact definition is used for the measurement.<\/p>\n<\/blockquote>\n\n\n\n

What does uptime mean?<\/h2>\n\n\n\n

Uptime generally refers to the period during which a system or service is available and operational.<\/p>\n\n\n\n

In website monitoring, this is often used to calculate a percentage value.<\/p>\n\n\n\n

Simplified:<\/p>\n\n\n\n

Available time\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 \u00d7 100\nTotal time<\/code><\/pre>\n\n\n\n
If a website was available during the entire considered period, the result is:<\/p>\n\n\n\n
100 % Uptime<\/code><\/p>\n\n\n\n
If there were any outages within this period, the measured value drops accordingly.<\/p>\n\n\n\n
What does downtime mean?<\/h2>\n\n\n\n
Accordingly, downtime refers to the time during which the monitored service was unavailable according to the definition used.<\/p>\n\n\n\n
At:<\/p>\n\n\n\n
99.9 % Uptime<\/code><\/p>\n\n\n\n
mathematically omitted:<\/p>\n\n\n\n
0,1 %<\/code><\/p>\n\n\n\n
of the considered period to downtime.<\/p>\n\n\n\n
Therefore, the time period to which the percentage value refers is always crucial.<\/p>\n\n\n\n
What does 99.9 % availability per month mean?<\/h2>\n\n\n\n
For simple calculation, let's assume a month with 30 days.<\/p>\n\n\n\n
30 days\n\u00d7 24 hours\n= 720 hours\n\n720 hours\n\u00d7 60 minutes\n= 43,200 minutes<\/code><\/pre>\n\n\n\n
At 99,9 %<\/code> Subject to availability 0,1 %<\/code> of this period:<\/p>\n\n\n\n
43,200 minutes\n\u00d7 0.001\n= 43.2 minutes<\/code><\/pre>\n\n\n\n
Purely arithmetically, they correspond 99,9 %<\/code> availability within a 30-day period approximately 43 minutes and 12 seconds downtime<\/strong>.<\/p>\n\n\n\n
\n
Important:<\/strong> This is a mathematical conversion and not a statement about what outages a specific hosting contract actually permits or how a provider defines its availability.<\/p>\n<\/blockquote>\n\n\n\n
What do different uptime values mean?<\/h2>\n\n\n\n
The differences become clearer when we compare several values with each other.<\/p>\n\n\n\n
Availability<\/th>Downtime at 30 days<\/th>Downtime at 365 days<\/th><\/tr><\/thead>
99 %<\/strong><\/td>7 hr. 12 min.<\/td>3 days 15 hours 36 min.<\/td><\/tr>
99,5 %<\/strong><\/td>3 hrs. 36 min.<\/td>1 day 19 hours 48 minutes.<\/td><\/tr>
99,9 %<\/strong><\/td>43 min. 12 sec.<\/td>8 hrs. 45 min. 36 sec.<\/td><\/tr>
99,95 %<\/strong><\/td>21 min. 36 sec.<\/td>4 hr. 22 min. 48 sec.<\/td><\/tr>
99,99 %<\/strong><\/td>4 min. 19 sec.<\/td>52 min. 34 sec.<\/td><\/tr>
99,999 %<\/strong><\/td>approx. 26 sec.<\/td>approx. 5 min. 15 sec.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Especially with high availability values, an additional nine makes a significant difference.<\/p>\n\n\n\n
Between 99,9 %<\/code> and 99,99 %<\/code> visually represents just another nine. Calculated over a year, however, the theoretical downtime drops from around 8 hours and 46 minutes to less than an hour.<\/p>\n\n\n\n
Why is the considered time period so important?<\/h2>\n\n\n\n
A percentage is of only limited significance without a reference period.<\/p>\n\n\n\n
For example, can:<\/p>\n\n\n\n
99.9 % per month\n\nand\n\n99.9 % per year<\/code><\/pre>\n\n\n\n
while mathematically describing the same percentage, the permitted or measured absolute downtime differs according to the length of the time period.<\/p>\n\n\n\n
This can also lead to different assessments of individual longer outages.<\/p>\n\n\n\n
An example with a two-hour outage<\/h2>\n\n\n\n
Assuming a website goes down once for two hours within a 30-day period.<\/p>\n\n\n\n
The month has:<\/p>\n\n\n\n
720 hours<\/code><\/p>\n\n\n\n
Of those, were:<\/p>\n\n\n\n
718 hours available<\/code><\/p>\n\n\n\n
The availability is therefore:<\/p>\n\n\n\n
718\n\u2500\u2500\u2500 \u00d7 100\n720\n\n= approx. 99.72 %<\/code><\/pre>\n\n\n\n
A single two-hour outage in this example would therefore already result in no 99,9 %<\/code> be achieved.<\/p>\n\n\n\n
Several short outages are added together<\/h2>\n\n\n\n
Downtime does not have to consist of a single long outage.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Outage 1: 5 minutes\nOutage 2: 12 minutes\nOutage 3: 8 minutes\nOutage 4: 10 minutes\n\nTotal: 35 minutes<\/code><\/pre>\n\n\n\n
For the calculation of availability, the total time evaluated as downtime within the considered period is normally taken into account.<\/p>\n\n\n\n
99.9 % does not mean \u201ea maximum of 43 minutes at a time\u201c<\/h2>\n\n\n\n
The frequently cited figure of approximately 43 minutes per 30 days is occasionally misunderstood.<\/p>\n\n\n\n
It does not mean:<\/p>\n\n\n\n
An outage may last a maximum of 43 minutes.<\/code><\/p>\n\n\n\n
She merely describes the total calculated downtime corresponding to a share of 0,1 %<\/code> corresponds to a 30-day period.<\/p>\n\n\n\n
This time could theoretically consist of a longer event or many short ones.<\/p>\n\n\n\n
Uptime and availability are frequently used as synonyms<\/h2>\n\n\n\n
In the web hosting and monitoring environment, the terms uptime and availability are often used almost synonymously.<\/p>\n\n\n\n
Technically, however, the term availability can be defined more comprehensively.<\/p>\n\n\n\n
For example, a system can be running and yet not be usefully accessible to the user.<\/p>\n\n\n\n
Therefore, it must always be clarified what is even considered in a specific measurement available<\/strong> valid.<\/p>\n\n\n\n
When is a website considered available?<\/h2>\n\n\n\n
That depends on the monitoring and the respective definition.<\/p>\n\n\n\n
For example, a simple monitor could use the following rule:<\/p>\n\n\n\n
HTTP 200\n\u2192 UP\n\nTimeout\n\u2192 DOWN\n\nHTTP 500\n\u2192 DOWN<\/code><\/pre>\n\n\n\n
Another monitor could additionally check whether specific content is present on the page.<\/p>\n\n\n\n
This allows two monitoring systems to evaluate the same website differently.<\/p>\n\n\n\n
An accessible homepage does not mean that everything is available<\/h2>\n\n\n\n
Assuming an online shop shows the following situation:<\/p>\n\n\n\n
Home page\n\u2192 working\n\nProduct pages\n\u2192 working\n\nShopping cart\n\u2192 working\n\nCheckout\n\u2192 Error<\/code><\/pre>\n\n\n\n
A monitor that checks exclusively the homepage could still:<\/p>\n\n\n\n
Up<\/code><\/p>\n\n\n\n
report.<\/p>\n\n\n\n
For the operator of the shop, there is still a significant functional disruption.<\/p>\n\n\n\n
\n
Note:<\/strong> An uptime value always describes the availability of what was actually monitored \u2013 not automatically the functionality of the entire website.<\/p>\n<\/blockquote>\n\n\n\n
What does an uptime monitor measure?<\/h2>\n\n\n\n
A classic website monitor periodically requests a defined URL and evaluates its response.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
08:00 \u2192 UP\n08:05 \u2192 UP\n08:10 \u2192 DOWN\n08:15 \u2192 DOWN\n08:20 \u2192 UP<\/code><\/pre>\n\n\n\n
The monitoring can then calculate availability values from these tests.<\/p>\n\n\n\n
We explain in detail how such systems work and what test methods exist at Website Monitoring: Monitor Availability and Outages<\/a>.<\/p>\n\n\n\n
The testing interval affects the measurement accuracy<\/h2>\n\n\n\n
A monitoring system does not automatically see every single second.<\/p>\n\n\n\n
If, for example, checks are only performed every five minutes, an outage can begin or end between two checks.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
10:00 Check \u2192 UP\n\n10:01 actual outage begins\n\n10:05 Check \u2192 DOWN\n\n10:07 website reachable again\n\n10:10 Check \u2192 UP<\/code><\/pre>\n\n\n\n
In this example, the actual outage lasted approximately six minutes.<\/p>\n\n\n\n
However, the exact start and end cannot be determined down to the second from the pure five-minute check points.<\/p>\n\n\n\n
Why different monitoring services can show different values<\/h2>\n\n\n\n
Multiple systems can monitor the same website and still report slightly different uptime values.<\/p>\n\n\n\n
Causes for this can include, for example:<\/p>\n\n\n\n
different check intervals\nvarious monitoring locations\ndifferent timeout limits\ndifferent success criteria\ndifferent handling of redirects\nconfirmation checks\nregional network issues\ndifferent measurement periods<\/code><\/pre>\n\n\n\n
Therefore, a discrepancy does not automatically mean that one of the systems is measuring incorrectly.<\/p>\n\n\n\n
Monitoring location and network path play a role<\/h2>\n\n\n\n
A monitor accesses the website from a specific network.<\/p>\n\n\n\n
If a network disruption occurs between this monitoring location and the server, the monitor can register an error even though visitors from other regions can still reach the website.<\/p>\n\n\n\n
For this reason, control tests from multiple locations can improve the validity of monitoring.<\/p>\n\n\n\n
What is an SLA?<\/h2>\n\n\n\n
SLA stands for Service Level Agreement<\/strong>.<\/p>\n\n\n\n
An SLA is a contractual agreement regarding defined performance characteristics of a service.<\/p>\n\n\n\n
An availability agreed upon therein could be, for example:<\/p>\n\n\n\n
99,9 %<\/code><\/p>\n\n\n\n
However, not only this number is crucial.<\/p>\n\n\n\n
An SLA should also define how availability is calculated and which conditions apply.<\/p>\n\n\n\n
99.9 % SLA is not automatically the same as 99.9 % measured uptime<\/h2>\n\n\n\n
This difference is particularly important.<\/p>\n\n\n\n
For a month, a monitoring system could, for example:<\/p>\n\n\n\n
99.87 % Uptime<\/code><\/p>\n\n\n\n
display.<\/p>\n\n\n\n
Whether this simultaneously violated a contractual SLA cannot be answered from this figure alone.<\/p>\n\n\n\n
The SLA may contain its own rules regarding which events are included in or excluded from the calculation.<\/p>\n\n\n\n
What else can an SLA regulate?<\/h2>\n\n\n\n
Depending on the provider and contract, the following points may be defined, for example:<\/p>\n\n\n\n
measurement period\n\nmeasurement method\n\naffected services\n\nscheduled maintenance work\n\nannounced maintenance windows\n\nforce majeure\n\nclient-caused disruptions\n\nDDoS or external events\n\nprovider's measurement point\n\nresponse and notification deadlines\n\nservice credits<\/code><\/pre>\n\n\n\n
Which rules actually apply follows exclusively from the respective contract or SLA.<\/p>\n\n\n\n
\n
Important:<\/strong> Never calculate a potential SLA claim solely based on a public uptime monitor. The specific contractual terms are decisive.<\/p>\n<\/blockquote>\n\n\n\n
Scheduled maintenance and availability<\/h2>\n\n\n\n
Scheduled maintenance is a good example of why a monitored metric and a contractually calculated availability can differ.<\/p>\n\n\n\n
An external monitor may register:<\/p>\n\n\n\n
Website unreachable for 20 minutes<\/code><\/p>\n\n\n\n
and does this time count as downtime.<\/p>\n\n\n\n
An SLA, on the other hand, can exclude announced maintenance windows from its availability calculation under certain conditions.<\/p>\n\n\n\n
Both values can thus be correct \u2013 they merely answer different questions.<\/p>\n\n\n\n
Distinguish between advertised availability and SLA<\/h2>\n\n\n\n
Marketing claims and contractual guarantees should also not be automatically equated.<\/p>\n\n\n\n
For example, a website can advertise high availability.<\/p>\n\n\n\n
Whether this results in a binding guarantee, an SLA, or a claim to a specific compensation depends on the specific contract terms.<\/p>\n\n\n\n
The percentage alone does not answer these questions.<\/p>\n\n\n\n
What does \u201e99.9 % Uptime Guarantee\u201c mean?<\/h2>\n\n\n\n
If a provider uses this term, you should check how the warranty is actually defined.<\/p>\n\n\n\n
For example, relevant factors include:<\/p>\n\n\n\n
Which services are covered?\n\nWhat period applies?\n\nHow is it measured?\n\nWhich outages count?\n\nWhat exceptions apply?\n\nWhat happens if it falls below the threshold?\n\nMust the customer claim compensation?<\/code><\/pre>\n\n\n\n
Only these conditions turn the percentage into a concretely evaluable commitment.<\/p>\n\n\n\n
100 % Availability is a special requirement<\/h2>\n\n\n\n
A mathematically measured availability of 100 %<\/code> within a specific period of time is of course possible if no downtime has been registered.<\/p>\n\n\n\n
A permanent commitment from 100 %<\/code> Availability, on the other hand, is much more far-reaching.<\/p>\n\n\n\n
Real IT systems consist of numerous components and dependencies:<\/p>\n\n\n\n
Network\n\nPower supply\n\nHardware\n\nOperating system\n\nWeb server\n\nDatabase\n\nDNS\n\nApplication\n\nExternal services<\/code><\/pre>\n\n\n\n
Redundancy can greatly increase availability, but it cannot completely eliminate technical risks in a mathematical sense.<\/p>\n\n\n\n
High availability requires more than one good server<\/h2>\n\n\n\n
The accessibility of a website does not depend solely on the web server's hardware.<\/p>\n\n\n\n
Simplified access can encompass several components:<\/p>\n\n\n\n
Visitor\n   \u2193\nDNS\n   \u2193\nNetwork\n   \u2193\nFirewall \/ Proxy \/ CDN\n   \u2193\nWeb server\n   \u2193\nPHP \/ Application\n   \u2193\nDatabase\n   \u2193\nExternal services<\/code><\/pre>\n\n\n\n
An error at various points in this chain can cause the website not to work as expected for the user.<\/p>\n\n\n\n
Redundancy improves availability<\/h2>\n\n\n\n
In high-availability systems, critical components are often designed to be redundant.<\/p>\n\n\n\n
This may concern, for example:<\/p>\n\n\n\n
Power supply\n\nNetwork connections\n\nServer\n\nStorage\n\nLoad balancer\n\nDatabases\n\nDNS infrastructure<\/code><\/pre>\n\n\n\n
If a component fails, another one can take over its task.<\/p>\n\n\n\n
Redundancy thus reduces so-called single points of failure.<\/p>\n\n\n\n
Redundancy alone does not guarantee high availability<\/h2>\n\n\n\n
Two systems are not automatically highly available just because they are duplicated.<\/p>\n\n\n\n
If both depend on the same faulty configuration, the same network, or the same application, for example, a common failure can still affect both systems.<\/p>\n\n\n\n
For true high availability, therefore, dependencies and failure scenarios must be considered as an overall system.<\/p>\n\n\n\n
What is a single point of failure?<\/h2>\n\n\n\n
A single point of failure is a single component whose failure can impair the entire system under consideration.<\/p>\n\n\n\n
Simplified:<\/p>\n\n\n\n
Website\n   \u2193\none server\n   \u2193\nserver fails\n   \u2193\nwebsite fails<\/code><\/pre>\n\n\n\n
Redundant architectures attempt to reduce such single critical dependencies.<\/p>\n\n\n\n
Uptime says nothing about the speed of a website<\/h2>\n\n\n\n
A website can:<\/p>\n\n\n\n
99.99 % achievable<\/code><\/p>\n\n\n\n
And yet:<\/p>\n\n\n\n
very slow<\/code><\/p>\n\n\n\n
to be.<\/p>\n\n\n\n
Availability and performance are different quality characteristics.<\/p>\n\n\n\n
If you want to check the speed of a website, you can find it under Measure website loading time and evaluate it correctly<\/a> the appropriate instructions.<\/p>\n\n\n\n
Core Web Vitals are not uptime measurements either<\/h2>\n\n\n\n
Core Web Vitals evaluate aspects of the user experience such as loading performance, interactivity, and visual stability.<\/p>\n\n\n\n
You are not answering the question of how many minutes a website was accessible within a month.<\/p>\n\n\n\n
You can find more about this at Core Web Vitals Explained: LCP, INP and CLS<\/a>.<\/p>\n\n\n\n
PageSpeed 100 does not mean 100% % uptime<\/h2>\n\n\n\n
Even a very good result on Google PageSpeed Insights says nothing about whether the website is available around the clock.<\/p>\n\n\n\n
Conversely, high uptime does not guarantee good PageSpeed scores.<\/p>\n\n\n\n
The tools look at different aspects:<\/p>\n\n\n\n
Website Monitoring\n\u2192 Availability\n\nPageSpeed Insights\n\u2192 Performance and user experience\n\nSearch Console\n\u2192 Search engine and indexing data<\/code><\/pre>\n\n\n\n
Uptime and error-free operation are also not the same thing<\/h2>\n\n\n\n
A website can be accessible and still have errors.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Homepage accessible\n\nContact form broken\n\nSearch function broken\n\nIndividual images missing\n\nCheckout broken<\/code><\/pre>\n\n\n\n
A simple uptime monitor might not detect such functional issues.<\/p>\n\n\n\n
How meaningful is a monthly value?<\/h2>\n\n\n\n
A monthly value is useful, but only shows a limited period.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
January  100.00 %\nFebruary 100.00 %\nMarch     99.10 %\nApril   100.00 %<\/code><\/pre>\n\n\n\n
A single monthly value can clearly highlight an exceptional incident.<\/p>\n\n\n\n
A longer-term perspective also helps to assess the stability of a service over several months.<\/p>\n\n\n\n
Do not simply average yearly uptime from monthly values<\/h2>\n\n\n\n
When measurement periods are of different lengths, you should not unreflectively calculate the arithmetic mean of percentage values.<\/p>\n\n\n\n
It is cleaner to add up all the available time and the entire time under consideration.<\/p>\n\n\n\n
Simplified:<\/p>\n\n\n\n
total available time\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 \u00d7 100\ntotal time under consideration<\/code><\/pre>\n\n\n\n
This correctly weights time periods of varying lengths.<\/p>\n\n\n\n
A concrete example<\/h2>\n\n\n\n
Assuming a website is monitored for 30 days and three confirmed outages occur:<\/p>\n\n\n\n
Outage 1: 7 minutes\nOutage 2: 11 minutes\nOutage 3: 4 minutes\n\nTotal downtime:\n22 minutes<\/code><\/pre>\n\n\n\n
The time period includes:<\/p>\n\n\n\n
43,200 minutes<\/code><\/p>\n\n\n\n
The available time is:<\/p>\n\n\n\n
43.178 minutes<\/code><\/p>\n\n\n\n
This results in:<\/p>\n\n\n\n
43,178\n\u2500\u2500\u2500\u2500\u2500\u2500 \u00d7 100\n43,200\n\n\u2248 99.949 %<\/code><\/pre>\n\n\n\n
For example, the monitoring could thus be rounded 99,95 %<\/code> display.<\/p>\n\n\n\n
Rounding can create differences<\/h2>\n\n\n\n
For high availability values, rounding can be relevant.<\/p>\n\n\n\n
An internally calculated value of, for example:<\/p>\n\n\n\n
99,9491 %<\/code><\/p>\n\n\n\n
can be represented with two decimal places as:<\/p>\n\n\n\n
99,95 %<\/code><\/p>\n\n\n\n
appear.<\/p>\n\n\n\n
Therefore, with SLA limits, it should be clear what precision is used for calculations and when rounding occurs.<\/p>\n\n\n\n
Why a single screenshot is not enough for an SLA evaluation<\/h2>\n\n\n\n
A screenshot of a monitoring dashboard can provide an important clue, but it is not automatically a complete contractual evaluation.<\/p>\n\n\n\n
For a reliable assessment, the following may also be relevant:<\/p>\n\n\n\n
full monitoring period\n\nmonitor configuration\n\ncheck interval\n\noutage history\n\nconfirmation checks\n\nmaintenance windows\n\ncontractual exclusions\n\nSLA calculation method<\/code><\/pre>\n\n\n\n
Therefore, the measurement data and the contractual evaluation should be considered separately.<\/p>\n\n\n\n
What should you check when given an availability status?<\/h2>\n\n\n\n
If you want to evaluate an uptime or availability specification, a few specific questions will help:<\/p>\n\n\n\n
What time period is being considered?\n\nWhat is being monitored?\n\nWhere is the measurement taken from?\n\nHow frequently is the check performed?\n\nWhen is a check considered DOWN?\n\nAre errors confirmed?\n\nAre maintenance periods included?\n\nIs this a metric, target, or SLA?\n\nWhat exceptions apply?<\/code><\/pre>\n\n\n\n
This gives the pure percentage the necessary context.<\/p>\n\n\n\n
Effective use of uptime monitoring<\/h2>\n\n\n\n
For the practical operation of a website, continuous monitoring is valuable primarily because disruptions can be quickly detected and chronologically documented.<\/p>\n\n\n\n
For example, a sensible sequence looks like this:<\/p>\n\n\n\n
Website is being monitored\n        \u2193\nCheck fails\n        \u2193\nError is confirmed\n        \u2193\nAlarm is triggered\n        \u2193\nIncident is investigated\n        \u2193\nWebsite is reachable again\n        \u2193\nMonitoring confirms UP\n        \u2193\nDocument downtime<\/code><\/pre>\n\n\n\n
We explain the technical setup and interpretation of such tests at Website Monitoring: Monitor Availability and Outages<\/a>.<\/p>\n\n\n\n
Uptime during sporadic issues<\/h2>\n\n\n\n
A high monthly uptime can mask individual disruptive issues.<\/p>\n\n\n\n
Assuming a website goes down for a few seconds or minutes almost every day.<\/p>\n\n\n\n
Nevertheless, the monthly percentage value may seem relatively high, while the recurring interruptions are disruptive to visitors or operators.<\/p>\n\n\n\n
Therefore, in addition to the total value, you should also look at the individual incidents.<\/p>\n\n\n\n
One long outage and many short outages are not the same<\/h2>\n\n\n\n
Mathematically, both situations can produce the same downtime:<\/p>\n\n\n\n
1 \u00d7 30 minutes\n\nor\n\n30 \u00d7 1 minute<\/code><\/pre>\n\n\n\n
However, the impact on business operations can vary.<\/p>\n\n\n\n
For example, many short interruptions can indicate a recurring technical problem, whereas a single longer outage may have been a one-time disruption.<\/p>\n\n\n\n
Viewing uptime in the context of business risks<\/h2>\n\n\n\n
How critical an outage is depends heavily on the website.<\/p>\n\n\n\n
For a simple informational page, ten minutes of downtime can have a comparatively minor impact.<\/p>\n\n\n\n
During a high-traffic online shop during a major promotional event, the exact same ten minutes can have significant consequences.<\/p>\n\n\n\n
Therefore, technically identical uptime can have a completely different business significance for different companies.<\/p>\n\n\n\n
Availability is just a metric<\/h2>\n\n\n\n
Die Qualit\u00e4t eines Hosting- oder Websystems l\u00e4sst sich nicht sinnvoll anhand einer einzigen Prozentzahl beurteilen.<\/p>\n\n\n\n
Weitere Faktoren sind beispielsweise:<\/p>\n\n\n\n
Performance\n\nStabilit\u00e4t\n\nSicherheit\n\nBackup-Konzept\n\nWiederherstellbarkeit\n\nSupport\n\nMonitoring\n\nWartung\n\nRedundanz\n\nFehlerbehebung<\/code><\/pre>\n\n\n\n
Eine hohe Uptime ist wichtig, ersetzt diese Faktoren aber nicht.<\/p>\n\n\n\n
H\u00e4ufige Missverst\u00e4ndnisse bei Uptime-Angaben<\/h2>\n\n\n\n
99,9 % bedeutet keinen Ausfall\n\n99,9 % bedeutet maximal\n43 Minuten pro Ausfall\n\n100 % im letzten Monat bedeutet\n100 % f\u00fcr immer\n\nUptime bedeutet schnelle Website\n\nUP bedeutet alle Funktionen\narbeiten fehlerfrei\n\nexterner Monitor und SLA\nm\u00fcssen denselben Wert zeigen\n\njede Wartung z\u00e4hlt zwingend\nals SLA-Downtime\n\njede Monitoring-St\u00f6rung ist\nein Serverausfall\n\n99,99 % ist fast dasselbe\nwie 99,9 %\n\nein hoher Uptime-Wert allein\nbeweist hochwertiges Hosting<\/code><\/pre>\n\n\n\n
Checkliste: Uptime richtig beurteilen<\/h2>\n\n\n\n
Prozentwert ansehen\n        \u2193\nZeitraum bestimmen\n        \u2193\nabsolute Downtime berechnen\n        \u2193\nMessmethode pr\u00fcfen\n        \u2193\n\u00fcberwachten Endpunkt pr\u00fcfen\n        \u2193\nPr\u00fcfintervall ber\u00fccksichtigen\n        \u2193\neinzelne Incidents ansehen\n        \u2193\nMonitoring-Standorte pr\u00fcfen\n        \u2193\nMesswert oder SLA?\n        \u2193\nSLA-Bedingungen lesen\n        \u2193\nWartungsfenster und\nAusnahmen ber\u00fccksichtigen\n        \u2193\ngesch\u00e4ftliche Auswirkungen\nbewerten<\/code><\/pre>\n\n\n\n
Summary<\/h2>\n\n\n\n
Uptime beziehungsweise Verf\u00fcgbarkeit beschreibt, welcher Anteil eines betrachteten Zeitraums ein System nach einer bestimmten Definition verf\u00fcgbar war.<\/p>\n\n\n\n
99,9 %<\/code> Verf\u00fcgbarkeit bedeutet rechnerisch 0,1 %<\/code> Downtime. Bei einem Zeitraum von 30 Tagen entspricht das ungef\u00e4hr 43 Minuten und 12 Sekunden. Auf ein Jahr mit 365 Tagen gerechnet entsprechen 99,9 %<\/code> ungef\u00e4hr 8 Stunden und 46 Minuten Downtime.<\/p>\n\n\n\n
Eine Prozentangabe ist jedoch nur dann wirklich aussagekr\u00e4ftig, wenn auch Messzeitraum und Messmethode bekannt sind. Pr\u00fcfintervall, Monitoring-Standort, Timeout, Erfolgskriterien und der tats\u00e4chlich \u00fcberwachte Endpunkt beeinflussen das Ergebnis.<\/p>\n\n\n\n
Besonders wichtig ist die Unterscheidung zwischen einer technisch gemessenen Uptime und einem vertraglichen SLA. Ein SLA kann eigene Messverfahren, Ausnahmen, Wartungsfenster und weitere Bedingungen definieren. Ein \u00f6ffentlicher Monitoring-Wert l\u00e4sst sich deshalb nicht automatisch als Nachweis f\u00fcr die Erf\u00fcllung oder Verletzung eines SLA verwenden.<\/p>\n\n\n\n
Auch Performance und Verf\u00fcgbarkeit sind getrennte Themen. Eine Website kann sehr schnell sein und trotzdem ausfallen \u2013 oder nahezu st\u00e4ndig erreichbar und gleichzeitig langsam sein.<\/p>\n\n\n\n
Eine Uptime-Zahl ist deshalb erst mit ihrem Kontext wirklich aussagekr\u00e4ftig: Was wurde gemessen, \u00fcber welchen Zeitraum, nach welchen Kriterien \u2013 und welche Verf\u00fcgbarkeit ben\u00f6tigt die Website f\u00fcr ihren tats\u00e4chlichen Einsatzzweck?<\/strong><\/p>","protected":false},"excerpt":{"rendered":"
Bei Webhosting, Cloud-Diensten und anderen Online-Services begegnen dir h\u00e4ufig Angaben wie 99,9 % Verf\u00fcgbarkeit, 99,95 % Uptime oder sogar 99,99 %. Auf den ersten Blick wirken diese Werte fast identisch. Rechnerisch k\u00f6nnen jedoch bereits wenige Nachkommastellen einen erheblichen Unterschied bei der m\u00f6glichen Ausfallzeit ausmachen. Gleichzeitig sagt eine Prozentzahl allein noch nicht, wie sie gemessen wurde, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"doc_category":[85],"doc_tag":[],"class_list":["post-22922","docs","type-docs","status-publish","hentry","doc_category-seo-monitoring"],"year_month":"2026-09","word_count":2894,"total_views":"3","reactions":{"happy":"0","normal":"0","sad":"0"},"author_info":{"name":"Silvio Mazenauer","author_nicename":"admin-curia","author_url":"https:\/\/www.curiaweb.ch\/en\/author\/admin-curia\/"},"doc_category_info":[{"term_name":"SEO & Monitoring","term_url":"https:\/\/www.curiaweb.ch\/en\/hilfe-kategorie\/seo-monitoring\/"}],"doc_tag_info":[],"knowledge_base_info":[],"knowledge_base_slug":[],"_links":{"self":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs\/22922","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/comments?post=22922"}],"version-history":[{"count":1,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs\/22922\/revisions"}],"predecessor-version":[{"id":22924,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs\/22922\/revisions\/22924"}],"wp:attachment":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/media?parent=22922"}],"wp:term":[{"taxonomy":"doc_category","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/doc_category?post=22922"},{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/doc_tag?post=22922"}],"curies":[{"name":"WP","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}