Ich lese jeden Hosting-Vertrag SLA Zeile für Zeile, weil ich Verfügbarkeit, Backup-Garantie und Haftung exakt einschätzen will. So erkenne ich, ob Uptime-Zusagen, Wiederherstellungszeiten und Entschädigungen wirklich zu meiner Website passen.
Zentrale Punkte
Bevor ich unterschreibe, halte ich die wichtigsten Prüfpunkte fest und ordne sie meinem Risiko ein, damit ich keine blinden Flecken übersehe und jede Zusage richtig deute. So gewichte ich die Bedeutung von Uptime, Support, Datensicherung, Sicherheit und Haftung im Kontext meiner Anwendung und meines Budgets, statt mich allein auf Marketingversprechen zu verlassen. Ich beachte, dass kleine Abweichungen in Prozentwerten große Auswirkungen auf Ausfallzeiten haben und dass Support-Zeiten am Wochenende völlig anders wirken können als werktags. Ich schaue außerdem genau hin, ob Backups nur existieren oder wirklich schnell und planbar zurückgespielt werden. Und ich prüfe, ob Haftungsgrenzen meinen potenziellen Schaden auch nur annähernd abfangen können.
- Uptime konkret: 99,9% vs. 99,99% und was als Downtime zählt
- Support-Reaktionszeiten: Uhrzeit-Logik und Eskalation
- Backups mit Aufbewahrung, Restore-Zeit und Kosten
- Sicherheit garantiert: DDoS, 2FA, Verschlüsselung
- Haftung und Gutschriften: Limits und Ausschlüsse
Verfügbarkeitsgarantie richtig lesen
Ich prüfe zuerst die Uptime-Zusage und rechne sie in Ausfallzeit pro Jahr um, damit ich das reale Risiko sehe und nicht nur Prozente. 99,9% bedeuten bis zu 8,76 Stunden Downtime pro Jahr, 99,99% nur etwa 52 Minuten, was für Shops oft entscheidend ist. Ich kontrolliere, ob der Vertrag geplante Wartung aus der Downtime herausrechnet und zu welchen Uhrzeiten diese Wartung stattfindet. Steht im Vertrag eine 99,9%-Quote, aber jeden Sonntag fallen 2 Stunden Wartung an, verschiebt das meinen Planungsspielraum massiv. Für tiefergehende Optimierung nutze ich ergänzende Hinweise wie die Uptime-Garantie optimieren, damit ich aus Prozenten konkrete Handlungsoptionen ableite.
Messmethodik und Geltungsbereich der Uptime
Ich kläre, wo der Anbieter misst: am Netzwerk-Edge, auf Hypervisor-Ebene oder als End-to-End-Check bis zur Web-Antwort. Eine Ping-Erreichbarkeit hilft mir wenig, wenn Datenbank- oder App-Layer down sind. Ich halte fest, ob nur die Infrastruktur zählt oder ob auch Plattformdienste (z. B. Managed DB, Object Storage) in die Verfügbarkeit einfließen. Ebenso wichtig: die Zeitzone der Messung, die Synchronisation der Uhren und ob nur vollständige Minuten zählen oder auch Sekunden. Ich prüfe, ob Drittanbieter (DNS, CDN, E-Mail) als Ausschluss gelten und plane dafür bewusst eigene SLAs ein.
Ich schaue mir die Definition von “Incident” an: Ab wann beginnt Downtime, und endet sie erst mit vollständiger Wiederherstellung oder bereits bei Degradierung. Ich verlange klare Regeln zu partiellen Ausfällen (z. B. nur ein Availability-Zone-Fehler) und wie diese in die Quote eingehen. Ohne saubere Messlogik reden wir bei Ausfällen oft aneinander vorbei.
Reaktionszeiten und Support wirklich bewerten
Ich verlasse mich nicht auf ein allgemeines Versprechen, sondern suche nach klaren Reaktionszeit-Fenstern für unterschiedliche Prioritäten. Reagiert der Support bei P1-Störungen in 30 oder 60 Minuten, zählt die Uhr ab Ticket-Eröffnung oder erst zu Bürozeiten, und läuft die Eskalation nachts weiter. Ich prüfe, ob Anfragen am Freitagabend bis Montag warten, weil das bei Ausfällen ganze Wochenenden kosten kann. Ich achte außerdem darauf, wie der Anbieter die Lösung (Time to Resolve) im Verhältnis zur ersten Reaktion regelt. Eine Stunde Antwort ohne konkreten Lösungsplan bringt mir wenig, wenn mein Shop weiter offline bleibt.
Monitoring, Logs und Incident-Transparenz
Ich fordere Zugriff auf eine Statusseite mit historischer Verfügbarkeit und Incident-Archiven, damit ich Ursachen und Wiederholungen erkenne. Ich prüfe, ob ich Metriken (CPU, RAM, I/O, Latenz) und Logs exportieren kann, um mein eigenes Monitoring, Alarme und SIEM zu füttern. Festgelegt werden sollten Log-Aufbewahrung, Zugriffskontrolle und die Möglichkeit, Audit-Logs für Admin-Aktivitäten zu erhalten. Ich frage nach Postmortems mit Root-Cause-Analyse, Korrekturmaßnahmen und Fristen, damit Lerneffekte verbindlich werden.
Backups, Aufbewahrung und Restore planbar machen
Ich schaue mir Backup-Frequenz, Aufbewahrungsdauer, Wiederherstellungszeit und mögliche Gebühren im Paket an, damit ich bei Datenverlust nicht improvisieren muss und echte Sicherheit habe. Tägliche Backups reichen für statische Seiten oft aus, während redaktionelle oder Shop-Systeme besser stündlich sichern. Aufbewahrung von 30 bis 90 Tagen schützt vor späten Entdeckungen, etwa bei unbemerkt eingeschleusten Fehlern. Wichtig ist die zugesagte Restore-Zeit, denn ein Backup nützt mir nichts, wenn die Rücksicherung in der Praxis Tage dauert. Für methodische Planung greife ich auf erprobte Backup-Strategien zurück, damit Frequenz, Test-Restore und Kosten zusammenpassen.
| Aspekt | Solide Formulierung | Risikoreiche Formulierung | Hinweis |
|---|---|---|---|
| Backup-Frequenz | Täglich oder stündlich | „Regelmäßig“ ohne Zahl | Zahlen schaffen Klarheit |
| Aufbewahrung | Mind. 30–90 Tage | Nur 7 Tage | Längere Historie ermöglicht Rollback |
| Restore-Zeit | „Innerhalb 2–6 Stunden“ | „So schnell wie möglich“ | Ohne Zeitfenster kein Plan |
| Kosten | Restore inklusive | 50 € pro Stunde | Kostenfallen vermeiden |
| Redundanz | Mehrere Standorte | Ein Standort | Schutz vor Ausfällen |
Ich teste mindestens quartalsweise eine Rücksicherung in eine Staging-Umgebung, damit ich im Ernstfall die Schritte kenne und die Dauer realistisch einschätzen kann. So halte ich den Wiederanlauf planbar und verhindere Überraschungen bei Rechten, Pfaden oder Datenbanken. Ich dokumentiere außerdem, wer Zugriff auf Backups hat, um Fehlbedienung zu verhindern. Das gilt vor allem für produktive Shops mit vielen Bestellungen pro Tag. Ein dokumentierter Restore-Prozess reduziert meine Risiken spürbar.
RPO, RTO und Backup-Qualität präzisieren
Ich schreibe mein Ziel-Recovery in zwei Werten fest: RPO (maximaler Datenverlust) und RTO (maximale Wiederanlaufzeit). Für einen Shop mit laufenden Bestellungen peile ich z. B. RPO ≤ 15 Minuten und RTO ≤ 2 Stunden an. Dann prüfe ich, ob die Backup-Frequenz, die Snapshot-Konsistenz (applikationskonsistent vs. crash-konsistent) und die Restore-Kapazitäten dazu passen. Ich frage nach Immutable-Backups oder WORM-Storage, damit Ransomware keine Historie zerstört. Verschlüsselung at rest setze ich voraus, genauso wie eine klare Regelung zur Schlüsselhoheit, falls der Anbieter KMS einsetzt.
Disaster Recovery und Hardwaretausch absichern
Ich prüfe, ob der Anbieter Hardwarefehler automatisch erkennt und defekte Komponenten in 30 bis 120 Minuten ersetzt, weil jede Minute bei P1-Störungen zählt. Steht die Wiederherstellung aus dem letzten Backup im Vertrag, und ist sie inklusive oder kostenpflichtig. Ich achte darauf, ob der Provider während des Tauschs Traffic automatisch auf Ersatzsysteme lenkt. Wichtig ist, dass die SLA die Verantwortlichkeiten klar benennt, damit ich im Ernstfall keine Zuständigkeitslücken habe. Eine klare DR-Regelung verschafft mir echte Resilienz gegen Ausfälle.
Shared Responsibility und Zuständigkeiten
Ich lasse mir eine Verantwortungsmatrix geben: Welche Schichten (Physik, Netzwerk, Hypervisor, OS, Middleware, App, Daten) verantwortet der Anbieter, was liegt bei mir. Patches für das Betriebssystem sind in Managed-Tarifen Aufgabe des Hosters, in Self-Managed-Varianten aber oft meine Pflicht. Ohne klare Trennlinie bleiben Sicherheits- und Verfügbarkeitslücken bis zum Ernstfall unsichtbar.
Sicherheit als Vertragsbestandteil verstehen
Ich erwarte in der SLA eine klare Zusage zu Firewalls, DDoS-Schutz, regelmäßigen Malware-Scans, TLS-Verschlüsselung und 2FA. Stehen diese Punkte nur im Marketingtext, fordere ich eine vertragliche Festschreibung mit Mindeststandards. Ich prüfe, ob Sicherheitsfunktionen im Basispaket enthalten sind oder ob Zusatzkosten die Kalkulation kippen. Wichtig ist auch, wie schnell Sicherheitslücken auf OS- oder Plattformebene gepatcht werden. Ohne feste Reaktions- und Update-Zeiten verliere ich bei Vorfällen wertvolle Zeit.
Compliance, Datenschutz und Datenstandort
Ich verlange einen Vertrag zur Auftragsverarbeitung mit dokumentierten TOMs, damit Rollen, Zugriffe, Lösch- und Aufbewahrungsfristen klar sind. Ich kläre, in welchen Ländern Daten gespeichert und verarbeitet werden, und ob Subunternehmer gelistet sind. Ich prüfe, wie Daten auf Wunsch exportiert und nach Vertragsende vollständig gelöscht werden, idealerweise mit Löschbestätigung. Für sensible Umgebungen fordere ich regelmäßige Sicherheitsüberprüfungen (z. B. Pentests) und definierte Fristen zur Behebung kritischer Findings.
Wartungsfenster transparent geregelt
Ich lasse mir genau erklären, wie oft Wartungen stattfinden, wann sie starten und wie lange sie typischerweise dauern, damit ich meine Spitzenzeiten schütze. Idealerweise liegen Wartungsfenster außerhalb meiner Hauptnutzung und sind frühzeitig angekündigt, etwa 48 Stunden vorher. Ich prüfe außerdem, ob die Wartung zur Verfügbarkeitsquote zählt oder ausdrücklich ausgenommen ist. Ohne diese Klarheit kann eine vermeintlich hohe Uptime-Zahl täuschen. Transparenz an dieser Stelle spart mir später viele Diskussionen.
Performance, Contention und Limits realistisch planen
Ich lasse mir harte Kennzahlen geben: garantierte vCPU-Performance, RAM-Zuteilung, IOPS- und Durchsatz-Limits für Storage, Rate Limits für APIs und Netzwerk. Ich frage nach Maßnahmen gegen “Noisy Neighbors” in Shared-Umgebungen und ob Bursting erlaubt ist. Für Datenbanken will ich wissen, wie viele gleichzeitige Verbindungen und Transaktionen unterstützt werden, bevor Drosselungen greifen. Ohne diese Zahlen drohen mir versteckte Engpässe genau dann, wenn ich Lastspitzen habe.
Netzwerkqualität und Connectivity
Ich prüfe, ob es verbindliche Aussagen zu Latenz, Paketverlust und Jitter zwischen Rechenzentren oder in definierte Regionen gibt. Ich frage nach redundanten Upstreams, BGP-Failover, DDoS-Scrubbing-Fenstern und ob Anycast- oder Geo-Routing eingesetzt wird. Für meine Use Cases mit Echtzeit-Komponenten (z. B. Live-Events) sind diese Netzwerk-SLAs oft relevanter als eine allgemeine Uptime-Zahl.
Haftung, Gutschriften und Limits weltlich prüfen
Ich lese das Haftungskapitel Zeile für Zeile und berechne, was Entschädigungen real bedeuten, damit ich meine Kosten einordnen kann. Ein Beispiel: 25% Gutschrift pro voller Ausfallstunde klingt gut, deckt aber mögliche Umsatzverluste selten ab. Ich prüfe die maximale Haftung, oft auf ein bis zwei Monatsgebühren limitiert, und entscheide, ob ich zusätzlichen Versicherungsschutz brauche. Ausschlüsse wie höhere Gewalt oder kundenseitige Fehler sind üblich, dürfen aber nicht zum Pauschal-Ausfall des Schutzes führen. Für Kontext zu Pflichten und Spielräumen lese ich auch die rechtliche Pflichten, um meine Erwartungen sauber zu kalibrieren.
Servicegutschriften richtig beantragen
Ich kläre, wie ich Credits anfordere: Fristen (oft 30 Tage), Nachweise (Ticket-IDs, Monitoring-Belege), Ansprechpartner und Bearbeitungszeiten. Ich prüfe, ob Gutschriften automatisch erfolgen oder aktiv beantragt werden müssen, und ob mehrere Incidents kumuliert werden. Wichtig ist, ob Gutschriften auf die nächste Rechnung angerechnet werden oder verfallen. So verhindere ich, dass mir vertraglich zugesagte Entschädigungen im Prozess verloren gehen.
Skalierbarkeit und Ressourcen ohne Unterbrechung
Ich achte darauf, wie schnell ich CPU, RAM, Storage und Traffic-Kontingente erweitern kann, damit ich Wachstum ohne Downtime abfedere. Wichtig ist ein definierter Bereitstellungszeitraum, etwa „innerhalb von 15 Minuten“, und transparente Preise vor dem Upgrade. Ich prüfe, ob vertikale Upgrades einen Reboot auslösen und ob horizontale Skalierung verfügbar ist. Für planbare Peaks halte ich zusätzliche Kapazitäten vor oder buche kurzfristige Kontingente. So bleibe ich auch bei Kampagnen, Releases oder Saisongeschäft handlungsfähig.
Änderungsmanagement und Deployments kontrollieren
Ich definiere mit dem Anbieter Change-Fenster für Updates am Stack, damit Releases, Schema-Migrationen und Konfigurationswechsel mit Rollback-Plan erfolgen. Ich frage nach Blue/Green- oder Canary-Optionen und ob Zero-Downtime-Deployments unterstützt werden. Für geschäftskritische Phasen plane ich Freeze-Perioden ein, damit keine überraschenden Änderungen in die Hauptsaison fallen.
Migration, Cutover und Exit sauber regeln
Ich lasse mir Migrationshilfe, Testumgebung und Cutover-Plan bestätigen. Ich reduziere DNS-TTL vor dem Umzug, teste einen Rückfall auf die Altumgebung und sichere ein Daten-Delta-Resync bis kurz vor Live-Schaltung. Beim Exit verlange ich definierte Exportformate (Dateien, Datenbanken, Objekte) und einen klaren Zeitplan für die endgültige Löschung inklusive Bestätigung. So bleibe ich beweglich, ohne Daten oder Zeit zu verlieren.
Preise, Overage und Anpassungsklauseln im Blick behalten
Ich zerlege die Kostenstruktur: Grundgebühr, Speicher-/Traffic-Overage, IP-Adressen, Snapshots, Restores, Support-Stufen, DDoS-Optionen. Ich prüfe Index- oder Preisanpassungsklauseln und ob diese mir ein Sonderkündigungsrecht geben. Ich achte auf Mindestlaufzeit, Kündigungsfrist und Verlängerungslogik, damit ich nicht ungewollt in lange Bindungen rutsche. Eine klare Kostenmatrix verhindert, dass mein Business Case durch Nebenkosten erodiert.
Vertrag lesen: typische Fallen vermeiden
Ich lasse mir vage Formulierungen in eindeutige Zahlen übersetzen, damit „so schnell wie möglich“ zu messbaren Werten wird. Ich entlarve versteckte Gebühren, etwa kostenpflichtige Restores oder limitierte Support-Kontingente, die meinen Monatspreis erhöhen. Ich prüfe Änderungsrechte: Darf der Anbieter Leistungsmerkmale einseitig anpassen, brauche ich ein Sonderkündigungsrecht. Ich achte auf saubere Kündigungsfristen und nachvollziehbare Exit-Prozesse inklusive Datenexport. So sorge ich dafür, dass ich jederzeit wechseln kann, ohne Daten zu verlieren.
Checkliste ohne Bulletpoints, aber glasklar
Ich frage mich: Erfüllt die Uptime-Zusage meine Umsatz- und Reputationsrisiken, und zählt die Wartung korrekt in die Quote. Wurde die Reaktionszeit für kritische Prioritäten mit Uhrzeiten, Eskalationsstufen und Wochenenden eindeutig definiert. Stimmen Backup-Frequenz, Aufbewahrung, Restore-Zeit und Gebühren mit meiner Änderungsrate und meinem Recovery-Ziel überein. Sind Sicherheit, Patching und 2FA vertraglich festgeschrieben und nicht nur als Marketing-Satz vorhanden. Sind Entschädigungen und Haftungsobergrenzen realistisch, oder brauche ich zusätzliche Absicherung.
Konkrete Schritte vor der Unterschrift
Ich fordere ein vollständiges Leistungsverzeichnis und gleiche es mit meinem Use Case ab, damit keine Lücke bleibt. Ich bitte um eine Testphase mit Monitoring meiner Kernmetriken, damit ich reale Performance sehe. Ich dokumentiere klare Eskalationskontakte für Tag, Nacht und Wochenende. Ich plane einen Restore-Test im Staging, bevor meine Seite live geht. Und ich sichere einen Exit-Plan mit sauberem Datenexport und abschließender Löschung sensibler Inhalte.
Kurz zusammengefasst
Ich lese jeden Vertrag aktiv, rechne Prozentangaben in echte Ausfallminuten um und prüfe, was als Downtime zählt. Ich verlange messbare Support- und Sicherheitszusagen statt unverbindlicher Floskeln. Ich plane Backups mit klarer Aufbewahrung, getesteter Wiederherstellung und fairer Kostenlogik. Ich bewerte Haftungsgrenzen an meinem potenziellen Schaden und entscheide, ob ich zusätzlich absichere. So wähle ich einen Hoster, der meine Ziele unterstützt und meine Risiken kontrollierbar hält.
