Für die meisten Websites sind 99,5 % bis 99,9 % Uptime ein realistisches und sinnvolles Ziel, also etwa 43 Minuten bis 3,6 Stunden Ausfall pro 30 Tage. Jede weitere Neun verkürzt die erlaubte Ausfallzeit um den Faktor 10 und verteuert Betrieb und Infrastruktur überproportional. Das richtige Ziel richtet sich nach den Kosten eines Ausfalls.
Das Wichtigste in Kürze
- 99,5–99,9 % sind für Unternehmensseiten und kleinere Shops erreichbar, wenn Betrieb, Updates und Überwachung stimmen.
- 99,99 % (4,3 Minuten pro Monat) erfordert redundante Infrastruktur, automatisches Failover und geübte Abläufe – mit einem Einzelserver nicht seriös zusagbar.
- Das Ziel folgt aus der Rechnung „Ausfallkosten gegen Zusatzaufwand“, nicht aus dem Wunsch nach vielen Neunen.
- Viele reale Ausfälle sind vermeidbar: abgelaufene Zertifikate, Domain-/DNS-Fehler, misslungene Updates.
- „100 %“ ist kein Ziel, sondern ein Warnsignal für unseriöse Versprechen.
Welche Uptime ist für welche Website realistisch?
Es gibt keinen universellen Zielwert, wohl aber vernünftige Bandbreiten. Die folgende Einordnung geht von „normalem“ Betrieb aus: ein gut gewarteter Webserver oder Managed-Hosting, aktuelle Software, Überwachung mit Alarm und ein Mensch, der innerhalb von Minuten bis Stunden reagiert.
| Website-Typ | Sinnvolles Ziel (30 Tage) | Erlaubter Ausfall | Typische Voraussetzungen |
|---|---|---|---|
| Privater Blog, Vereinsseite | 99 % – 99,5 % | 3,6 – 7,2 Std. | Solides Shared Hosting, Zertifikats- und Domain-Überwachung |
| Unternehmensseite, Leadgenerierung | 99,5 % – 99,9 % | 43 Min. – 3,6 Std. | Guter Hoster, Caching, Update-Routine, Alarm mit Reaktionsweg |
| Onlineshop (klein bis mittel) | 99,9 % | 43 Min. | Getrennte Prüfung von Checkout und Zahlungsweg, Wartung nachts, Notfallplan |
| Buchungs-/Terminsystem, SaaS, API mit Kunden | 99,9 % – 99,95 % | 22 – 43 Min. | Redundanz einzelner Komponenten, mehrere Messstandorte |
| Zahlungsabwicklung, kritische Infrastruktur | 99,99 %+ | ≤ 4,3 Min. | Mehrere Standorte/Zonen, automatisches Failover, 24/7-Bereitschaft |
Diese Werte sind Orientierung aus dem Betriebsalltag, keine Marktstatistik. Wer eine belastbare Zahl für die eigene Seite braucht, sollte sie aus den eigenen Ausfallkosten ableiten – dazu der nächste Abschnitt.
Wie leiten Sie das richtige Ziel aus den Ausfallkosten ab?
Jede zusätzliche Neun kostet Geld: bessere Hosting-Stufe, Redundanz, Bereitschaft, Tests. Sie lohnt sich nur, wenn die vermiedenen Ausfallkosten höher sind als die Mehrkosten. Die Rechnung ist einfach:
Ausfallkosten pro Monat = Ausfallzeit (Min.) × Schaden pro Minute
Angenommen (Beispielwerte), ein Shop setzt 3.000 € pro Tag um, davon entfallen 80 % auf 16 aktive Stunden. Schaden pro Minute in den aktiven Stunden: 2.400 € ÷ 960 Minuten = 2,50 €. Bei 99,5 % (216 Minuten Ausfall pro Monat) wären das bis zu 540 €, bei 99,9 % (43 Minuten) etwa 108 €, bei 99,99 % (4,3 Minuten) ungefähr 11 €. Der Sprung von 99,5 % auf 99,9 % spart im Beispiel rund 430 € im Monat; der Sprung von 99,9 % auf 99,99 % nur noch etwa 97 €. Kostet die Zusatzinfrastruktur für die vierte Neun 300 € monatlich, lohnt sie sich hier nicht – bei 30.000 € Tagesumsatz schon.
Die Rechnung ist bewusst grob: Sie vernachlässigt Folgeschäden wie verlorene Stammkunden, Werbekosten, die ins Leere laufen, oder Reputation. Eine ausführliche Methode finden Sie in Was kostet ein Website-Ausfall?. Auch dort gilt: Setzen Sie Ihre eigenen Zahlen ein, keine fremden Durchschnittswerte.
Warum kostet jede weitere Neun überproportional mehr?
Der Grund ist, dass Ausfallursachen ungleich verteilt sind. Die ersten Neunen erreichen Sie durch Sorgfalt: Updates mit Rückfallplan, Überwachung, rechtzeitige Zertifikatserneuerung, ein ordentlicher Hoster. Die späteren erreichen Sie nur durch Beseitigung einzelner Ausfallpunkte (Single Points of Failure) und durch Automatisierung der Reaktion:
- Bis etwa 99,5 %: Das Wesentliche ist Disziplin. Typische Ausfälle sind menschliche Fehler, abgelaufene Zertifikate, volle Festplatten, hängende Dienste.
- Etwa 99,9 %: Verlangt schnelle Erkennung (Minuten, nicht Stunden), einen dokumentierten Behebungsweg und Reaktionsbereitschaft, auch nachts und am Wochenende, sofern der Schaden dies rechtfertigt.
- Etwa 99,95–99,99 %: Ein Mensch, der nachts reagiert, ist zu langsam. Es braucht automatisches Failover, redundante Datenbanken und Netzwerkanbindung, getestete Wiederherstellung.
- Darüber: Mehrere Standorte oder Anbieter, bewusst geübte Ausfälle. Das ist der Bereich großer Plattformen, nicht kleiner Websites.
Hinzu kommt der Zusammenhang aus der Reihenschaltung: Die Gesamtverfügbarkeit liegt immer unter der des schwächsten Bausteins (Rechnung in Was bedeutet Uptime?). Wer 99,99 % zusagen will, aber ein einzelnes Hosting-Paket mit 99,9 % Herstellerzusage nutzt, rechnet sich ein Ziel, das physikalisch nicht erreichbar ist.
Was verursacht reale Ausfälle – und was davon ist vermeidbar?
In kleinen und mittleren Websites sind die häufigsten Ursachen selten exotisch. Eine ausführliche Übersicht liefert Ausfallursachen von Websites; hier die praxisnahe Sortierung nach Beeinflussbarkeit:
| Ursache | Vermeidbar? | Maßnahme |
|---|---|---|
| Abgelaufenes TLS-Zertifikat | Fast immer | SSL-Monitor mit Vorwarnung, automatische Erneuerung prüfen (Ratgeber) |
| Falsche DNS-Änderung, abgelaufene Domain | Meist | DNS-Monitor, Änderungsprotokoll, Auto-Renew |
| Fehlgeschlagenes Update/Deployment | Zu großen Teilen | Staging, Backup, Rollback, Wartungsfenster |
| Ressourcenengpass (RAM, Festplatte, Prozesse) | Zum Teil | Server-Überwachung, Caching, Limits |
| Lastspitze, Bot-Traffic | Zum Teil | Caching, Rate-Limits, skalierbares Hosting |
| Hardware-/Netzwerkproblem beim Hoster | Kaum | Redundanz, Hoster-Wahl, Notfallplan |
| Fehler bei Drittanbietern (Zahlung, CDN, Skripte) | Kaum | Getrennt überwachen, Ausweichwege, Timeouts |
Der Befund: Ein erheblicher Teil der Ausfälle liegt in Ihrer Hand und ist mit Routine und Überwachung zu verhindern. Ein ehrliches Ziel orientiert sich zuerst an dem, was Sie selbst steuern können.
Wovon hängt die Ausfallzeit pro Monat konkret ab?
Die monatliche Ausfallzeit ist das Produkt aus drei Größen: Wie oft tritt eine Störung auf, wie schnell wird sie erkannt, wie schnell wird sie behoben?
Ausfallzeit = Anzahl Störungen × (Erkennungszeit + Reaktionszeit + Behebungszeit)
Angenommen (Beispielwerte), eine Seite hat im Schnitt 2 Störungen pro Monat. Ohne Monitoring bemerkt der Betreiber sie nach durchschnittlich 60 Minuten (durch Besucher oder zufälliges Nachsehen), die Behebung dauert 20 Minuten: 2 × 80 = 160 Minuten → 99,63 %. Mit Monitoring (5-Minuten-Intervall, 2 Bestätigungen: Erkennung ca. 7 Minuten, Reaktion 5 Minuten) und gleicher Behebungszeit: 2 × 32 = 64 Minuten → 99,85 %. Ohne einen einzigen Ausfall weniger zu haben, sinkt die Ausfallzeit um 60 %. Mit einem Notfallplan, der die Behebung auf 10 Minuten drückt, sind es 2 × 22 = 44 Minuten (99,90 %).
Die Rechnung zeigt, warum Erkennung und Vorbereitung die günstigsten Hebel sind: Sie wirken auf jede Störung, ohne dass die Ursachen beseitigt sein müssen. Der Weg zur nächsten Neun führt anschließend über weniger Störungen (Qualität von Updates, Redundanz) und automatische Behebung.
Wie unterscheiden sich Hosting-Stufen in der erreichbaren Uptime?
Konkrete Prozentwerte je Anbieter nennen wir nicht, weil sie sich ändern und vertraglich definiert sind. Qualitativ gilt aber:
| Setup | Typische Stärke | Typische Schwäche | Realistisches Ziel |
|---|---|---|---|
| Günstiges Shared Hosting | Wenig Aufwand, geringe Kosten | Nachbarn teilen Ressourcen, begrenzter Einfluss auf Wartung | Eher 99 % bis 99,5 % |
| Managed Hosting / Managed WordPress | Wartung, Backups und Überwachung durch den Anbieter | Ein Server bleibt Einzelpunkt | 99,5 % bis 99,9 % |
| VPS oder Root-Server in Eigenregie | Volle Kontrolle | Alles liegt bei Ihnen: Updates, Absicherung, Wiederherstellung | Je nach Betrieb 99 % bis 99,9 % |
| Redundant (Load Balancer, mehrere Server, replizierte Datenbank) | Ausfall einer Komponente bleibt unsichtbar | Komplexität, Kosten, mehr Fehlerquellen bei Konfiguration | 99,9 % bis 99,99 % |
Die rechte Spalte ist eine Einordnung aus Erfahrung, keine Zusage. Sie zeigt vor allem: Die Infrastruktur setzt eine Obergrenze, der Betrieb entscheidet, wie nah Sie ihr kommen.
Warum 100 % kein sinnvolles Versprechen ist
Wartungsfenster, Softwarefehler, Rechenzentrumsprobleme, Zertifikats- und DNS-Fehler oder Fehler bei Zulieferern kommen auch bei gutem Betrieb vor. Hinzu kommt: Die Zahl 100 % ist gar nicht messbar. Ein Monitor sieht Stichproben, und selbst große Plattformen veröffentlichen Zielwerte unterhalb von 100 %. Seriöse Angaben nennen Zielwert, Messzeitraum und Messmethode. Wer „lückenlose“, „garantiert unterbrechungsfreie“ oder „100 %“-Überwachung bzw. -Verfügbarkeit verspricht, verspricht zu viel – das gilt auch für Anbieter von Monitoring.
Wie setzen Sie das Ziel mit einem Fehlerbudget um?
Statt „möglichst viel Uptime“ ist ein konkretes Ziel mit Budget praktikabler. Das Fehlerbudget ist die Ausfallzeit, die Sie sich pro Zeitraum erlauben. Es macht Entscheidungen greifbar: Ist das Budget nahezu verbraucht, verschieben Sie riskante Änderungen; ist reichlich übrig, können Sie Neuerungen einspielen.
Ziel: 99,9 % in 30 Tagen = 43,2 Minuten Budget. Nach 20 Tagen sind bereits 31 Minuten Ausfall angefallen (u. a. ein misslungenes Plugin-Update). Verbleiben 12,2 Minuten für die restlichen 10 Tage. Konsequenz: größere Updates auf den Folgemonat schieben, Backups und Rollback-Tests vorziehen. Das Budget liefert die Entscheidungsgrundlage, nicht das Bauchgefühl.
Wie sich das mit Alarmschwellen verbindet, beschreibt das Google-SRE-Workbook zum Alerting auf SLOs (siehe Quellen); die Grundbegriffe erklärt SLA, SLO und SLI.
Was können Sie selbst für höhere Uptime tun?
- Ablaufdaten überwachen: Zertifikate, Domain, DNS-Einträge. Sie sind die günstigste Uptime-Maßnahme überhaupt.
- Updates planen: Außerhalb der Hauptnutzungszeit, mit Backup und Rückweg; Wartung vorher ankündigen (Wartungsfenster planen).
- Caching nutzen: Ein guter Seitencache verkraftet Lastspitzen, die sonst den Server überfordern (Cache-Control richtig setzen).
- Schnell erkennen: Ein Monitor mit Bestätigung und mehreren Kanälen verkürzt die Zeit bis zur Reaktion – und damit direkt die Ausfalldauer.
- Vorbereitet sein: Wer weiß, wen er anruft und welche Schritte folgen, spart Minuten (Ausfall-Notfallplan).
- Abhängigkeiten kennen: Welche Drittanbieter muss die Seite zwingend erreichen? Für jeden einen Ausweichweg oder zumindest einen Timeout planen.
Sollte das Ziel je Tageszeit oder Saison unterschiedlich sein?
Ein Monatsbudget behandelt jede Minute gleich, der Schaden tut das nicht. Eine Stunde Ausfall um 3 Uhr nachts kostet einen Shop meist weniger als eine Stunde am Cyber Monday. Praktisch bedeutet das: Legen Sie Zeiten fest, in denen Änderungen tabu sind (Kampagnen, Saisonspitzen), und Zeiten, in denen Wartung gut passt (nachts, Wochenendmorgen). Planen Sie vor Spitzenzeiten einen Lasttest und kürzere Intervalle ein. Das ist kein höheres Uptime-Ziel, sondern ein klügerer Einsatz des vorhandenen Budgets – und für die meisten kleineren Betriebe wirksamer als eine zusätzliche Neun.
Häufige Fehler bei der Zielsetzung
| Fehler | Problem | Besser |
|---|---|---|
| Ziel höher als die Infrastruktur trägt | Zusage unerreichbar, Frust, Vertragsrisiko | Ziel an Architektur und Budget ausrichten |
| Hoster-SLA mit eigenem Ziel gleichsetzen | Eigene Anwendung, DNS und Zertifikate sind nicht abgedeckt | Eigene Messung von außen |
| Ein Ziel für alle Seiten und Funktionen | Überinvestition bei Unwichtigem, Unterinvestition bei Kritischem | Ziele je Dienst (Startseite ≠ Checkout) |
| Ziel ohne Messung | Nicht überprüfbar | Monitore und Berichte einrichten |
| Nur Prozent, keine Minuten | Abstrakt, Entscheidungen fallen schwer | Fehlerbudget in Minuten kommunizieren |
Grenzen und Einordnung
Zielwerte sind Absichten, keine Garantien; ob sie erreicht werden, zeigt nur die Messung. Auch die Messung hat Grenzen: Ein Monitor mit 5-Minuten-Intervall erkennt keine Störungen von wenigen Minuten sicher, und ein einzelner Messstandort kann regionale Probleme übersehen. Hinzu kommt, dass Prozentwerte über Wochen und Monate gemittelt werden, während Besucher einzelne Momente erleben – eine halbe Stunde Ausfall am Black-Friday-Vormittag wiegt schwerer als am Sonntagmorgen. Bewerten Sie deshalb neben dem Prozentwert immer auch wann Ausfälle auftraten und was sie gekostet haben. Verträge, Haftung und Gutschriften sind Sache von Fachleuten für Vertragsrecht; dieser Text ersetzt keine Beratung.
Checkliste: Ihr realistisches Uptime-Ziel in sieben Schritten
- Schaden pro Ausfallminute abschätzen (Umsatz, Leads, Folgekosten).
- Kritische Funktionen benennen und getrennt betrachten.
- Einen Zielwert mit Zeitraum festlegen (z. B. 99,9 % in 30 Tagen) und in Minuten umrechnen.
- Einzelne Ausfallpunkte der Architektur auflisten und bewerten, ob das Ziel damit erreichbar ist.
- Überwachung für die kritischen Funktionen und für Ablaufdaten einrichten.
- Reaktionsweg festlegen: Wer wird wann wie benachrichtigt?
- Monatlich auswerten: Budget verbraucht? Ursachen? Ziel anpassen?
Wie unterstützt Sie UPTIMESHIELD bei Zielsetzung und Kontrolle?
Im Dashboard können Sie je Monitor ein SLA-Ziel festlegen und sehen das Fehlerbudget für die letzten 30 Tage. Zertifikatsablauf überwachen SSL-Monitore mit Warnungen 30, 14, 7, 3 und 1 Tag vor Ablauf; DNS-Monitore und Heartbeat-Monitore decken weitere vermeidbare Ausfallursachen ab (Monitortypen). Wartungsfenster zählen nicht in die Verfügbarkeit, damit geplante Arbeiten Ihr Budget nicht verfälschen. Mit mehreren Messstandorten (Pro bis 3, Max bis 6 zusätzliche) reduzieren Sie Fehlalarme durch Mehrheitsentscheid; ohne zusätzliche Standorte misst nur ein Standort. Eine öffentliche Statusseite zeigt Kunden transparent, wie es um Ihre Verfügbarkeit steht – ohne Schönfärberei.
Quellen und weiterführende Standards
Externe Links führen zu den Original-Spezifikationen und offiziellen Dokumentationen. Die Einordnung und die Beispielrechnungen stammen aus der Messmethodik von UPTIMESHIELD.
Selbst prüfen: Testen Sie jetzt, ob Ihre Website erreichbar ist und wie schnell sie antwortet – mit dem Uptime Checker.