Ein Onlineshop, seit Jahren im Betrieb. Eines Tages funktioniert „In den Warenkorb“ nicht mehr. Der Button wird beim Klick grau und bleibt es. Keine Fehlermeldung, kein Hinweis, nichts im Postfach. Die Seite sieht normal aus. Nur kaufen kann niemand mehr.
Dieser Zustand hielt 37 Tage.
Niemand hatte etwas geändert. Kein Update im Shop, kein neues Plugin, keine Anpassung am Design. Geändert hatte sich der Server — durch die Wartung, für die der Betreiber bezahlt.
Was tatsächlich passiert ist
In dem Shop steckt ein Produktkonfigurator. Der Kunde stellt sich sein Produkt zusammen, und beim Klick auf den Warenkorb-Button erzeugt der Konfigurator ein Vorschaubild davon. Dieses Bild rendert nicht WordPress, sondern ein eigenes Programm daneben, das dafür einen Browser im Hintergrund startet.
Bei einem Upgrade des Betriebssystems ist eine Systembibliothek verschwunden, die dieser Hintergrund-Browser braucht. Aus Sicht des Servers völlig korrekt: Das Bauteil war veraltet, aktuelle Software braucht es nicht mehr. Aus Sicht des Shops eine Katastrophe, denn die eingesetzte Browser-Version stammt aus dem Jahr 2020 und verlangt es fest.
Dazu kam ein zweiter Fehler, der mit dem ersten nichts zu tun hatte: Der Startbefehl für dieses Zusatzprogramm enthielt einen Tippfehler — ein einzelnes fehlendes Zeichen in einer Pfadangabe. Dadurch wurde das Programm mit einer falschen Version seiner Verwaltungssoftware gestartet und stürzte beim Hochfahren sofort ab. Knapp eine Million Mal, über fünf Wochen hinweg, ohne dass irgendwo eine Meldung entstand.
Zwei Fehler, unabhängig voneinander, beide im selben Bereich: der Schicht zwischen dem Server und der eigentlichen Anwendung. Genau dort, wo sich niemand zuständig fühlt.
Für den Kunden im Shop sah das aus wie ein Button, der nicht reagiert.
Die technische Seite dieser Fehlersuche habe ich auf purin.dev aufgeschrieben — mit Befehlen, Fehlermeldungen und der Stelle, an der ich eine Stunde in die falsche Richtung gelaufen bin. Es sind zwei Beiträge geworden, einer je Ursache: die Neustartschleife des Prozessmanagers und die fehlende Systembibliothek. Hier geht es um die Frage davor: Warum konnte das überhaupt passieren, und wen trifft es noch.
„Managed“ bedeutet etwas anderes, als die meisten denken
Managed Hosting ist ein gutes Produkt. Der Anbieter hält das Betriebssystem aktuell, spielt Sicherheitspatches ein, überwacht die Hardware, sichert den Server. All das musst du dann nicht selbst können, und für die meisten Betriebe ist das genau richtig.
Was Managed Hosting nicht abdeckt: ob deine Anwendung nach diesen Updates noch läuft. Das ist keine Lücke im Angebot, sondern die Grenze davon. Der Anbieter kennt deine Software nicht. Er weiß nicht, dass da ein Konfigurator mitläuft, der einen sechs Jahre alten Browser startet. Er kann es auch nicht wissen.
Die Zuständigkeit endet an der Stelle, an der deine Anwendung anfängt — und genau dort fängt sie niemand auf, wenn du dafür niemanden hast.
Der Denkfehler steckt im Wort. „Gemanagt“ klingt nach „jemand kümmert sich“. Gemanagt wird der Server. Nicht das, was darauf läuft.
37 Tage, in denen niemand etwas gemerkt hat
Das ist für mich der schwerwiegendere Teil des Falls. Nicht dass etwas kaputtging — das passiert. Sondern dass es fünf Wochen lang niemandem auffiel.
Der Warenkorb-Button ging beim Klick in den Ladezustand und blieb dort. Der Shop hat den Ausfall des Konfigurators nie abgefangen. Es gab keine Fehlermeldung für den Kunden, keine Meldung an den Betreiber, keinen Eintrag irgendwo, wo jemand hinschaut. Auch die knapp eine Million Abstürze im Hintergrund lösten nichts aus.
Für den Kunden im Shop sieht das nicht nach einem Serverproblem aus. Es sieht nach einer Seite aus, die nicht funktioniert. Er geht weg und kommt nicht wieder. Diese Kunden tauchen in keiner Statistik auf, weil sie nie einen Bestellvorgang begonnen haben. Im Shop-Backend sieht ein solcher Monat aus wie ein schlechter Monat, nicht wie ein Defekt.
Ein Monitoring, das den entscheidenden Klick tatsächlich durchspielt, kostet im Monat weniger als eine einzige verlorene Bestellung. 37 Tage Ausfall zu bemerken, weil sich irgendwann ein Kunde beschwert, kostet deutlich mehr.
Das eigentliche Risiko ist das Wissen, nicht der Code
Der Shop wurde vor rund sechs Jahren gebaut. Seitdem haben mehrere Dienstleister und mehrere Entwickler daran gearbeitet, jeder hat ihn irgendwie am Laufen gehalten. Heute konnte niemand mehr sagen, warum das Ding so gebaut ist, wie es gebaut ist.
Das finde ich an dem Fall wichtiger als die fehlende Bibliothek. Eine Bibliothek rüstet man nach. Aber die Entscheidung, warum ein Vorschaubild von einem separaten Programm gerendert wird statt im Shop selbst, steht nirgends. Sie steckte im Kopf von jemandem, der nicht mehr da ist.
Ein großer Dienstleister schützt davor nicht. Es heißt nur, dass mehr Leute da sind, die das Wissen nacheinander verlieren können.
Was du für deine eigene Website mitnimmst
Vier Fragen, die du beantworten können solltest. Wenn du bei einer davon passen musst, weißt du, wo du anfängst.
Läuft neben WordPress noch etwas anderes?
Konfiguratoren, Buchungssysteme, PDF- oder Angebotsgeneratoren, Kartendienste, Bildbearbeitung, Schnittstellen zur Warenwirtschaft. Alles, was nicht als Plugin installiert ist, sondern als eigenes Programm daneben läuft. Genau diese Teile bekommen keine Update-Benachrichtigung im WordPress-Dashboard.
Weiß noch jemand, wie diese Teile funktionieren?
Nicht „wer hat es gebaut“, sondern: Wen kannst du heute anrufen, der es erklären kann. Wenn die Antwort ein Firmenname ohne konkrete Person ist, ist die Antwort vermutlich niemand.
Merkst du es, wenn etwas ausfällt — oder merken es deine Kunden zuerst?
Ein Monitoring, das nur prüft, ob die Startseite lädt, hätte in diesem Fall fünf Wochen lang grün gemeldet. Der Shop war ja erreichbar. Was fehlte, war ein Test, der den Warenkorb-Klick tatsächlich durchspielt.
Was passiert im Frontend, wenn ein Bauteil nicht antwortet?
Ein sichtbarer Hinweis und eine Alternative sind besser als ein Button, der ewig lädt. Diesen Ausfall abzufangen ist rund ein halber Tag Arbeit. Gegen 37 Tage ohne Umsatz ist das keine Rechnung, über die man lange nachdenkt.
Was ich in dem Fall gemacht habe
Zuerst den Hotfix: Prozessverwaltung sauber neu aufgesetzt, fehlende Bibliothek von Hand nachgerüstet, Shop lief wieder. Ehrlicherweise ist das eine Reparatur außerhalb der Paketverwaltung — beim nächsten Serverumzug ist sie weg.
Deshalb läuft parallel das, was eigentlich nötig ist. Der Hintergrund-Browser und die Bibliotheken darum kommen auf einen aktuellen Stand, damit das alte Bauteil gar nicht mehr gebraucht wird. Dazu kommt eine Verfügbarkeitsprüfung, die Alarm schlägt, statt still zu bleiben. Und das Abfangen im Shop, damit ein Ausfall künftig ein Hinweis für den Kunden ist und kein Button, der lädt und lädt.
Drei Stunden Fehlersuche für ein Problem, das nicht in der Software steckte, sondern in deren Alter und in einem Tippfehler. Gefunden habe ich es, weil ich wusste, wonach ich suchen muss. Ohne dieses Vorwissen wäre der Shop noch länger gestanden.
Häufige Fragen
Was deckt Managed Hosting genau ab?
Betriebssystem, Sicherheitsupdates, Server-Backups, Verfügbarkeit der Hardware. Deine Anwendung und deren Abhängigkeiten gehören nicht dazu, außer du hast das ausdrücklich vereinbart. Das steht so oder ähnlich in jedem Vertrag — es liest nur selten jemand.
Kann ich Server-Updates einfach abschalten?
Bei manchen Anbietern geht das, sinnvoll ist es nicht. Ein Server ohne Sicherheitsupdates ist das deutlich größere Risiko. Die Lösung ist nicht, weniger zu aktualisieren, sondern die eigene Software so aktuell zu halten, dass sie Updates verträgt.
Woran erkenne ich, ob meine Website betroffen sein kann?
Wenn irgendetwas auf deiner Seite Bilder, PDFs oder Vorschauen erzeugt, Termine verwaltet oder Daten mit einem anderen System austauscht, läuft dafür meistens ein eigenes Programm auf dem Server. Frag deinen Dienstleister, welche Teile das sind und wie alt sie sind. Die Antwort dauert fünf Minuten.
Reicht es, wenn mein Hoster den Server überwacht?
Der Hoster überwacht, ob der Server läuft. Das ist etwas anderes als die Frage, ob dein Shop verkaufen kann. In diesem Fall war der Server die ganzen 37 Tage über tadellos verfügbar. Was du brauchst, ist eine Prüfung des Vorgangs, mit dem du Geld verdienst.
Lohnt es sich, ein sechs Jahre altes System zu modernisieren?
Der Vergleich ist nicht „modernisieren oder so lassen“. Er ist „geplant modernisieren oder ungeplant reparieren“. Ungeplant heißt: am Freitagabend, mit Umsatzausfall, zum Stundensatz. Was es kostet, hängt davon ab, wie viel vom alten Aufbau erhalten bleiben kann — das lässt sich vorher in ein paar Stunden klären.
Sprich mit mir über dein Projekt
Wenn du nicht sicher bist, was auf deinem Server außer WordPress noch läuft, schau ich es mir an. Ich sage dir, welche Teile problematisch werden, was davon dringend ist und was warten kann.