Kurz und einfach erklärt
Fällt die Kasse Ihres Shops aus, haben Kunden Fragen. Ohne Antwort bestellen manche doppelt. Andere schreiben an den Support.
Eine Statusseite informiert Kunden bei einer Störung. Sie muss auch laufen, wenn der Shop ausfällt. Darum läuft sie getrennt vom Shop.
Der Beitrag zeigt, wie man so eine Seite aufbaut. Er zeigt auch, welche Meldungen man in welcher Reihenfolge schreibt.
Wir übernehmen Überwachung, Statusseite und Meldungen als ein Paket.
Wenn die Kasse eines Shops ausfällt, beginnt für den Betreiber ein technisches Problem – für den Kunden beginnt eine Frage. Bei 57 Prozent der befragten Betreiber kostete der jüngste größere Ausfall mehr als 100.000 US-Dollar, bei jedem fünften lag der Schaden über einer Million US-Dollar (Uptime Institute). Ein Teil dieser Kosten entsteht nicht in der Technik, sondern in der Stille davor: Bestellungen werden mehrfach ausgelöst, der Support bekommt dieselbe Frage hundertmal, und wer keine Antwort findet, kauft anderswo. Eine Statusseite ist eines der preiswertesten Gegenmittel – vorausgesetzt, sie läuft nicht auf derselben Maschine wie der Shop. Dieser Beitrag beschreibt, was auf so eine Seite gehört, wie sie technisch angebunden wird und welche Meldungen in welcher Reihenfolge herausgehen.
Das Wichtigste in Kürze
- Die Statusseite gehört nicht auf die Infrastruktur, über die sie berichtet. Über neun Jahre entfielen rund zwei Drittel der öffentlich gemeldeten Ausfälle auf Drittanbieter für IT- und Rechenzentrumsdienste (Uptime Institute).
- Der Shop antwortet im Wartungsmodus mit 503, nicht mit 200 oder 404: Der Code steht für vorübergehende Überlastung oder geplante Wartung (IETF, RFC 9110). Der Antwortkopf Retry-After nennt dazu die voraussichtliche Dauer.
- Drei Meldungen tragen einen Vorfall: erste Meldung ohne Ursache, Zwischenstand zur zugesagten Uhrzeit, Abschluss mit Nacharbeit. Verlässlich ist wichtiger als ausführlich – der Zwischenstand geht auch dann heraus, wenn es nichts Neues gibt.
- Sind personenbezogene Daten betroffen, läuft eine zweite Uhr: Meldung an die Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden (Art. 33 DSGVO), Benachrichtigung Betroffener in klarer und einfacher Sprache (Art. 34 DSGVO).
- Die genannte Rückkehrzeit ist eine Planungsgröße, keine Prognose. Der BSI-Standard 200-4 rechnet die geforderte Wiederanlaufzeit vom Ausrufen des Notfalls bis zur Inbetriebnahme der Ersatzlösung (BSI).
Warum die Stille mehr kostet als die Störung
Ein Ausfall schreibt zwei Rechnungen. Die erste ist technisch und wird in Minuten gemessen. Die zweite entsteht im Kopf des Kunden und läuft weiter, wenn die Technik längst wieder arbeitet. Bei 57 Prozent der befragten Betreiber kostete der jüngste größere Ausfall mehr als 100.000 US-Dollar, bei jedem fünften lag der Schaden über einer Million US-Dollar (Uptime Institute). In derselben Auswertung gibt etwa jeder Zehnte an, dass der letzte Ausfall schwerwiegende oder gravierende Auswirkungen hatte (Uptime Institute, Ausfallanalyse 2026). Diese Zahlen stammen aus dem Rechenzentrumsbetrieb, die Mechanik im Handel ist dieselbe: Wer nicht weiß, ob seine Bestellung angekommen ist, löst sie erneut aus, ruft an, schreibt eine Nachricht – und erzeugt Arbeit, die nach dem Ausfall noch Tage bindet.
Der Support ist dabei der teuerste Kanal. Eine Störung von 90 Minuten in einer Abendspitze erzeugt dieselbe Frage in jedem Postfach, in jedem Chatfenster und an jeder Telefonleitung, und jede Antwort wird einzeln getippt. Eine Statusseite dreht das Verhältnis um: Sie beantwortet die Frage einmal an einer Stelle, auf die Support, Newsletter, Profile in sozialen Netzen und die Fehlerseite des Shops verweisen. Der Aufwand verschiebt sich vom hundertfachen Beantworten zum dreifachen Schreiben. Voraussetzung ist, dass die Störung überhaupt bemerkt wird, bevor der erste Kunde anruft – dafür sorgt die laufende Überwachung der Erreichbarkeit, nicht die Statusseite selbst.
Eine Statusseite auf derselben Maschine ist keine Statusseite
Was auf eine Statusseite gehört – und was nicht
Eine Statusseite ist kein Blog und kein Ticketsystem. Sie beantwortet vier Fragen in dieser Reihenfolge: Was ist betroffen, seit wann, was wird getan, und wann kommt die nächste Nachricht. Alles Weitere ist Ballast. Ein häufiger Fehler ist die Ursachenangabe in der ersten Meldung. Sie ist zu diesem Zeitpunkt in der Regel eine Vermutung, sie muss später korrigiert werden, und die Korrektur kostet mehr Vertrauen als das anfängliche Schweigen über den Grund. Die erste Meldung nennt deshalb die Wirkung, nicht die Ursache – und sie nennt sie in der Sprache der Kundschaft, nicht in der des Betriebs.
Das wichtigste Element ist der Zeitstempel. Eine Seite, auf der ohne Uhrzeit steht, dass an einer Lösung gearbeitet wird, ist von einer eingefrorenen Seite nicht zu unterscheiden, und Besucher unterstellen im Zweifel das Schlimmere. Jede Meldung trägt darum Datum und Uhrzeit samt Zeitzone, und der Kopf der Seite trägt zusätzlich den Zeitpunkt der letzten Aktualisierung. Wer die Uhrzeit automatisch aus einem System zieht, prüft vorher, ob dieses System im Störungsfall überhaupt antwortet; die Einrichtung einer eigenen Verfügbarkeitsmessung liefert dafür die Datenquelle, die unabhängig genug ist.
| Element der Seite | Welche Frage es beantwortet | Typischer Fehler | Woran es sich prüfen lässt |
|---|---|---|---|
| Statusband oben | Ist der Shop gerade nutzbar? | Nur zwei Zustände: läuft oder läuft nicht | Ein dritter Zustand für eingeschränkten Betrieb ist vorhanden |
| Zeitstempel der Aktualisierung | Wie alt ist diese Auskunft? | Uhrzeit ohne Zeitzone oder ganz ohne Uhrzeit | Zeitzone steht im Text, Abgleich mit einer zweiten Uhr |
| Systemzeilen | Was genau ist betroffen? | Ein einziger Gesamtstatus für alles | Kasse und Zahlung sind getrennt ausgewiesen |
| Zusage der nächsten Meldung | Wann erfahre ich mehr? | Offener Text ohne feste Uhrzeit | Die nächste Uhrzeit steht in jeder Meldung |
| Handlungshinweis | Was soll ich jetzt tun? | Fehlt, Bestellungen werden mehrfach ausgelöst | Ein Satz zu Doppelbestellungen und offenen Zahlungen |
| Kontaktweg | Wo frage ich nach? | Verweis auf ein Formular im ausgefallenen Shop | Der Weg liegt außerhalb der betroffenen Anwendung |
Was nicht auf die Seite gehört, ist ebenso klar umrissen: Namen einzelner Mitarbeitender, interne Systembezeichnungen, Schuldzuweisungen an Dienstleister und alles, was Rückschlüsse auf Kundendaten zulässt. Auch Zahlenspiele mit Verfügbarkeitswerten sind hier fehl am Platz – wer im laufenden Ausfall eine Jahresquote nennt, wirkt, als rechne er den Vorfall klein. Wie teuer ein Ausfall tatsächlich wird, lässt sich später in Ruhe gegen den entgangenen Umsatz rechnen; während der Störung ist das ohne Belang.
Die vier Systemzeilen: Shop, Kasse, Zahlung, Suche
Ein einziger Gesamtstatus ist für den Kunden wenig wert, weil er die falsche Frage beantwortet. Wer eine Sendung verfolgen möchte, braucht eine andere Auskunft als jemand, der gerade bezahlen will. Vier Zeilen decken den Handel erfahrungsgemäß ab: der Shop selbst, die Kasse, die Zahlungsanbindung und die Suche mitsamt Katalog. Jede Zeile trägt einen eigenen Zustand und einen eigenen Verlauf. Der Verlauf ist dabei kein Schmuck. Er zeigt, ob es sich um einen einmaligen Aussetzer oder um das dritte Ereignis an diesem Tag handelt, und nimmt der wiederkehrenden Frage nach der Häufigkeit die Schärfe.
Zeile 1: Shop erreichbar
Gemessen wird der Abruf einer echten Kategorieseite mit Statuscode und Antwortzeit, nicht der Ping auf die Startseite. Ein Shop, der die Startseite aus dem Zwischenspeicher liefert, während der Katalog steht, gilt sonst als verfügbar.
Zeile 2: Kasse
Die Kasse braucht eine eigene Zeile, weil sie die teuerste Minute des Ausfalls trägt. Geprüft wird der Weg bis zur Zahlungsauswahl, nicht nur die Erreichbarkeit der Adresse.
Zeile 3: Zahlungsanbindung
Diese Zeile bricht erfahrungsgemäß meist außerhalb des eigenen Hauses. Sie wird getrennt geführt, damit die Meldung sagen kann, dass der Shop läuft und lediglich ein Zahlungsweg aussetzt.
Zeile 4: Suche und Katalog
Eine ausgefallene Suche erzeugt keinen Fehlerstatus, sondern leere Ergebnisseiten. Gemessen wird deshalb ein Suchbegriff mit bekanntem Treffer, nicht die Erreichbarkeit des Suchdienstes.
Verlauf je Stunde
Ein Punkt je Stunde über 24 Stunden ist dicht genug für den Tagesverlauf und grob genug, um lesbar zu bleiben. Wer feiner auflöst, erzeugt ein Diagramm, das im Vorfall niemand liest.
Getrennter Betrieb
Host, DNS-Zone und Zertifikat der Statusseite stehen außerhalb der Shop-Umgebung. Ohne diese Trennung misst die Seite nur, ob sie selbst erreichbar ist.
Die Zeile für die Zahlung verdient besondere Aufmerksamkeit, weil sie erfahrungsgemäß selten im eigenen Haus bricht. Über neun Jahre hinweg entfielen rund zwei Drittel der öffentlich gemeldeten Ausfälle auf Drittanbieter für IT- und Rechenzentrumsdienste (Uptime Institute). Für die Statusseite heißt das: Auch ein Ausfall, den man nicht selbst verursacht hat, gehört gemeldet – mit dem Hinweis, dass die Ursache außerhalb liegt, und ohne Namensnennung. Wie sich Abhängigkeiten von Drittanbietern vorher entschärfen lassen, ist ein Thema für den ruhigen Betrieb, nicht für den Vorfall.
Der technische Unterbau: 503 und Retry-After
Solange der Shop nicht antwortet, entscheidet der Webserver darüber, was Besucher und Suchmaschinen sehen. Der passende Statuscode dafür ist 503. Er zeigt an, dass der Server die Anfrage vorübergehend nicht bearbeiten kann – wegen Überlastung oder geplanter Wartung – und dass sich der Zustand nach einiger Verzögerung voraussichtlich auflöst (IETF, RFC 9110). Der Unterschied zu den beiden verbreiteten Fehlgriffen ist erheblich. Eine Fehlerseite mit Status 200 erklärt der Suchmaschine, dieser Inhalt sei genau so gemeint. Ein 404 erklärt ihr, die Adresse gebe es nicht mehr. Beide Auskünfte überdauern den Ausfall und wirken danach weiter.
Zum 503 gehört der Antwortkopf Retry-After. Er nennt entweder ein Datum oder eine Anzahl Sekunden und teilt dem Empfänger mit, wie lange der Dienst voraussichtlich nicht verfügbar ist (IETF, RFC 9110). Für Besucher bleibt das unsichtbar, für Crawler ist es die Grundlage der Entscheidung, wann sie es erneut versuchen. Bei geplanten Arbeiten ist der Wert leicht zu setzen, weil das Wartungsfenster ohnehin vorab geplant wird. Bei ungeplanten Störungen setzt man einen zurückhaltenden Wert und aktualisiert ihn mit dem nächsten Zwischenstand.
# Wartungs- und Störungsmodus: Shop antwortet mit 503,
# die Statusseite liegt auf einem anderen Host und bleibt unberührt.
map $request_uri $wartung {
default 1;
~^/status-hinweis/ 0; # lokale Hinweisseite bleibt erreichbar
~^/assets/hinweis/ 0;
}
server {
# ... Shop-Konfiguration ...
if ($wartung) {
return 503;
}
error_page 503 @hinweis;
location @hinweis {
root /srv/hinweis;
rewrite ^ /hinweis.html break;
add_header Retry-After 1800 always;
add_header Cache-Control "no-store" always;
}
}
Für Suchmaschinen hat der Statuscode messbare Folgen. Serverfehler der Klasse 5xx und der Code 429 sorgen dafür, dass die Crawler von Google das Crawling vorübergehend verlangsamen; bereits indexierte Adressen bleiben zunächst im Index und werden erst später entfernt (Google-Crawling-Infrastruktur). Antwortet der Server wieder mit 2xx, erhöht Google die Crawling-Frequenz nach und nach (Google-Crawling-Infrastruktur). Für eine Störung von Stunden ist das folgenlos. Wer allerdings über Tage im Wartungsmodus bleibt, verliert Sichtbarkeit, unabhängig davon, wie gut die Statusseite formuliert ist. Solche Zustände sieht früh, wer ein Auge auf den Protokollen und der Alarmierung hat.
Ein älterer Hinweis aus dem Search-Central-Blog von Google gilt weiter: Geplante Ausfallzeiten, die nicht eindeutig als solche gekennzeichnet sind, können die Reputation einer Website negativ beeinträchtigen (Google Search Central 2011). Ebenso wichtig ist die Gegenrichtung. Der 503 ist kein Dauerzustand: Sein langandauernder Einsatz kann als Anzeichen dafür gewertet werden, dass eine Adresse dauerhaft nicht erreichbar ist, und zum Ausschluss aus dem Index führen (Google Search Central 2011). Wer den Wartungsmodus setzt, hinterlegt im selben Arbeitsschritt die Erinnerung, ihn wieder zu entfernen.
Die Meldungsspur: erste Meldung, Zwischenstand, Abschluss
Drei Meldungen tragen einen normalen Vorfall. Die erste geht heraus, sobald die Störung bestätigt ist, und nennt ausschließlich die Wirkung: welches System betroffen ist, seit wann, und wann die nächste Nachricht kommt. Sie enthält weder eine Ursache noch einen Zeitpunkt der Behebung. Der Zwischenstand folgt zur angekündigten Uhrzeit – auch dann, wenn es nichts Neues gibt. Genau dieser Fall ist der wichtigste: Eine Meldung mit dem Inhalt, dass sich der Stand nicht geändert hat und der nächste in dreißig Minuten folgt, kostet eine halbe Minute Arbeit und ersetzt hundert Nachfragen.
Die dritte Meldung schließt den Vorfall. Sie nennt Zeitraum, Wirkung und Nacharbeit und – an dieser Stelle, nicht vorher – die Ursache, soweit sie geklärt ist. Kunden mit angebrochenen Bestellungen bekommen hier eine konkrete Anweisung: erneut versuchen, abwarten oder den Support ansprechen. Wer eine vereinbarte Reaktionszeit im Notfall hat, koppelt die Taktung der Meldungen daran, statt sie im laufenden Vorfall neu auszuhandeln. Die Textbausteine dafür entstehen im ruhigen Betrieb und liegen dort, wo sie auch ohne den Shop erreichbar sind.
Drei Meldungen, drei verschiedene Aufgaben
Wenn Daten betroffen sind: Fristen und Sprache
Eine Störung ist nicht automatisch ein Datenschutzvorfall, aber der Übergang ist fließend. Die Verordnung verlangt vom Verantwortlichen Maßnahmen, die die Fähigkeit sicherstellen, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste auf Dauer zu gewährleisten (Art. 32 DSGVO), und ausdrücklich auch die Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen (Art. 32 DSGVO). Verfügbarkeit ist damit keine reine Komfortfrage, sondern Teil der technischen und organisatorischen Maßnahmen.
Wird bei der Störung der Schutz personenbezogener Daten verletzt, läuft eine zweite Uhr. Die Meldung an die Aufsichtsbehörde erfolgt unverzüglich und möglichst binnen 72 Stunden, nachdem die Verletzung bekannt wurde (Art. 33 DSGVO). Besteht voraussichtlich ein hohes Risiko für die Rechte und Freiheiten Betroffener, werden diese unverzüglich benachrichtigt, und zwar in klarer und einfacher Sprache (Art. 34 DSGVO). Diese Benachrichtigung ist etwas anderes als die Statusmeldung und gehört nicht in dieselbe Bausteinsammlung – wohl aber in denselben Notfallplan, zusammen mit der Frage, wessen Zugänge im Vorfall zu entziehen sind.
- Statusseite auf eigenem Host, in eigener DNS-Zone und ohne Abhängigkeit von der Shop-Datenbank betreiben
- Drei Textbausteine vorbereiten: erste Meldung, Zwischenstand, Abschluss – je mit Platzhaltern für System, Zeitraum und nächste Uhrzeit
- Feste Taktung festlegen und in der ersten Meldung nennen, statt sie im laufenden Vorfall auszuhandeln
- Wartungsmodus mit Status 503 und Retry-After hinterlegen und den Pfad der Hinweisseite von der Sperre ausnehmen
- Meldeweg für Datenschutzvorfälle getrennt führen, mit den Fristen aus Art. 33 und Art. 34 DSGVO
- Kontaktweg außerhalb des Shops bereithalten, damit Rückfragen nicht am ausgefallenen System hängen
- Nach jedem Vorfall Zeitstempel, Meldungen und Nacharbeit archivieren, damit die nächste Schätzung auf Messwerten beruht
Wiederanlauf: welche Zeit die Statusseite eigentlich nennt
Die Frage, wann es wieder läuft, hat eine Fachbezeichnung. Der BSI-Standard 200-4 nennt die geforderte Wiederanlaufzeit RTO und beschreibt sie so: Die RTO umfasst den Zeitraum vom Ausrufen des Notfalls bis zum Zeitpunkt der geforderten Inbetriebnahme der BC-Lösung, also der Ersatzlösung (BSI). Das ist eine Planungsgröße aus dem Normalbetrieb, keine Prognose für den laufenden Vorfall. Wer sie auf der Statusseite nennt, sollte sie vorher an einer geübten Wiederherstellung gemessen haben – sonst wird aus einer Planungsgröße eine Zusage, die der Vorfall in der Regel nicht einhält.
Derselbe Standard beschreibt auch, wozu die externe Kommunikation da ist: In jedes Notfallszenario sind diverse Interessengruppen direkt oder indirekt involviert (BSI), und als oberstes Ziel der externen Kommunikation nennt der Standard, die Kommunikation zu kontrollieren, um Reputationsschäden zu minimieren (BSI). Übersetzt in den Handel heißt das: Die Statusseite ist der Ort, an dem die eigene Darstellung entsteht, bevor sie in Bewertungsportalen und sozialen Netzen von anderen geschrieben wird. Wer schweigt, überlässt die Deutung denen, die am lautesten sind.
In der Formulierung lohnt sich Zurückhaltung. Eine Angabe wie voraussichtlich gegen 15:30 ist eine Auskunft; spätestens 15:30 ist eine Zusage, die nichts kostet, solange sie hält, und viel kostet, wenn sie fällt. Sinnvoll ist deshalb, den nächsten Meldezeitpunkt fest zuzusagen und die Rückkehrzeit als Schätzung zu kennzeichnen. Bei Vorfällen rund um Zeitsprünge kommt eine weitere Fehlerquelle hinzu, weil Zeitstempel und geplante Aufgaben auseinanderlaufen können; das ist ein eigenes Thema und beim Wechsel von der Sommer- auf die Winterzeit jedes Jahr erneut zu prüfen.
Die Statusseite prüfen, bevor sie gebraucht wird
Eine Statusseite, die im Ernstfall zum ersten Mal aufgerufen wird, ist ein Versprechen ohne Deckung. Die Probe besteht aus zwei Teilen. Der erste prüft die Erreichbarkeit unter erschwerten Bedingungen: Der Shop wird bewusst in den Wartungsmodus gesetzt, und aus einem Netz außerhalb des eigenen Rechenzentrums wird geprüft, ob die Statusseite antwortet, welchen Status sie liefert und ob Retry-After gesetzt ist. Der zweite Teil prüft den Weg dorthin. Zeigt die Fehlerseite des Shops den Verweis? Kennt der Support die Adresse? Steht sie in der Fußzeile der Newsletter-Vorlage?
Diese Probe gehört in denselben Turnus wie die Rückspielprobe aus der Datensicherung. Ein Termin im Quartal reicht erfahrungsgemäß aus, solange er tatsächlich stattfindet und protokolliert wird. Wer den Notfallplan für den Ernstfall ohnehin pflegt, hängt die Prüfung der Statusseite an dieselbe Liste; ein eigener Prozess dafür lohnt sich selten. Wichtig ist, dass die Probe den Weg von außen nimmt: Aus dem eigenen Netz sieht fast jede Trennung sauber aus.
Der Alarm im Beispiel ist der klassische Fehler: Die Statusseite steht getrennt, aber ihr Kontaktformular führt zurück in den ausgefallenen Shop. Solche Rückkopplungen finden sich in fast jeder ersten Fassung – im Bildpfad, in der Schriftart, im Einwilligungsbanner, im Zählpixel. Jede externe Abhängigkeit der Statusseite ist eine Abhängigkeit zu viel; im Zweifel wird die Seite ohne Skripte und mit eingebetteten Schriften ausgeliefert. Wer im laufenden Vorfall Unterstützung braucht, findet sie im Notfall-Support.
Was der Wartungsvertrag daraus macht
Eine Statusseite ist schnell gebaut und langsam gepflegt. Die Arbeit steckt nicht im HTML, sondern in der Bereitschaft dahinter: Jemand muss die Störung bemerken, die erste Meldung innerhalb weniger Minuten formulieren, den Zwischenstand zur angekündigten Uhrzeit setzen und den Abschluss schreiben, auch wenn der Vorfall um 23:40 endet. Genau an diesem Punkt ist eine Statusseite in einem Wartungsvertrag mit Bereitschaft besser aufgehoben als in der Verantwortung einer einzelnen Person, die auch einmal im Urlaub ist.
In der Praxis hängt die Statusseite an derselben Kette wie die Überwachung: Die Messung erkennt den Ausfall, die Bereitschaft bestätigt ihn, und dieselbe Bereitschaft setzt die Meldung. Ohne diese Kopplung entsteht ein häufiger Zustand – eine gepflegte Statusseite, die im Vorfall zwei Stunden lang alle Systeme als verfügbar ausweist, weil das Umstellen in der Aufregung untergegangen ist. Welche Bausteine dabei zusammengehören, steht in der Übersicht der Leistungen.
Der Zeitstempel auf einer Statusseite sagt mehr über die Organisation dahinter aus als jede Verfügbarkeitszahl im Jahresbericht.
Einstieg in kleinen Schritten
Der Einstieg braucht keine eigene Anwendung. Eine einzelne HTML-Datei auf einem Host, der nichts mit dem Shop zu tun hat, deckt den größten Teil des Nutzens ab: Statusband, vier Zeilen, Zeitstempel, drei Meldungen darunter. Gepflegt wird sie zunächst von Hand, und genau das ist im ersten Jahr ein Vorteil, weil jede Änderung eine bewusste Entscheidung bleibt. Automatik lohnt sich erst, wenn die Meldedisziplin steht – eine automatisch gesetzte Ampel ist nur so verlässlich wie die Messung dahinter.
Der zweite Schritt ist die Verdrahtung: Fehlerseite des Shops, Signatur des Supports, Fußzeile des Newsletters und Profile in sozialen Netzen verweisen auf dieselbe Adresse. Der dritte Schritt ist die Probe unter Last. Erst danach lohnt sich die Frage nach automatisch gesetzten Zuständen, und dann zuerst dort, wo die Messung ohnehin schon sauber läuft – etwa im Monitoring der Kasse und der Transaktionen, das den teuersten Teil des Ausfalls zuerst sichtbar macht.
Statusseite und Bereitschaft zusammen denken
Quellen und Studien
Verwandte Artikel
Disaster Recovery: Shop nach dem Ernstfall wiederherstellen
Disaster Recovery für Online-Shops: DR-Plan, getestete Wiederherstellung, RTO und RPO definieren – über reine Backups hinaus. Schritt für Schritt.
Server-Logs im Shop: Wie lange IP-Adressen bleiben dürfen
Wie lange dürfen IP-Adressen in Server-Logs liegen? Was die DSGVO verlangt, was die fünf Wochen des BfDI bedeuten und wie Rotation, Kürzung und Backups wirken.
WordPress-Sicherheitsupdates: Was alte Zweige noch bekommen
WordPress 7.1.2 schloss eine kritische Lücke, der Fix kam als Gefälligkeit bis 4.7 zurück. Was ältere Zweige erhalten, was nicht und wann der Sprung fällig ist.