Eine Sonde, die den Chat nur anpingt, wenn der Checkout bricht

Eine Kaufseite fiel nachts aus, und niemand hat es bis zum Morgen bemerkt. Die Anzeigen liefen weiter, die Klicks landeten auf einer Seite mit Ladekringel, und ein Tag Traffic hat nichts gekauft. Die Statusseite des Hosters war die ganze Zeit grün, weil der Server lief; kaputt war die Seite. Danach wollte ich eine Sonde, die die Seite so anschaut wie ein Kunde.

Was sie prüft

Nicht "antwortet der Server". Sie ruft die Checkout-URL mit einem normalen Browser-User-Agent und zehn Sekunden Timeout ab und prüft drei Dinge: Status 200, Antwortzeit unter einer Schwelle und eine Zeichenkette, die im HTML vorkommen muss. Die Zeichenkette ist die Beschriftung des Bezahlknopfs. Fehlt der Knopf, ist die Seite aus Kundensicht kaputt, egal was der Statuscode sagt.

Sie läuft alle zehn Minuten aus einer Cron-Zeile auf einem Rechner, der immer an ist.

Warum nur bei Zustandswechsel

Die erste Version hat bei jeder fehlgeschlagenen Prüfung eine Zeile in den Chat geschrieben. Nach einer Woche hatten alle den Kanal stummgeschaltet. Eine Meldung alle zehn Minuten ist Rauschen, auch wenn die Nachricht schlecht ist, und Rauschen trainiert Leute darauf, genau die eine Nachricht zu ignorieren, die zählt.

Die zweite Version hält eine winzige Zustandsdatei mit dem letzten bekannten Zustand, up oder down, und einem Zähler für aufeinanderfolgende Fehler. Sie schreibt nur, wenn der Zustand kippt.

fails = fails + 1 if not ok else 0
new_state = "down" if fails >= 2 else "up"
if new_state == state:
    return
post(f"checkout {new_state}: {url} ({reason})")
state = new_state

Zwei Fehler hintereinander, bevor es "down" heißt, damit eine einzelne langsame Antwort oder ein Schluckauf im CDN niemanden weckt. Eine erfolgreiche Prüfung reicht für "wieder da", mit einem kurzen Zusatz, wie lange es weg war. Zwischen diesen zwei Nachrichten ist der Kanal still, und das heißt: Eine Nachricht im Kanal ist immer eine Neuigkeit.

Sie handelt nie selbst

Die Sonde pausiert nichts, fasst die Anzeigen nicht an, startet keinen Server neu. Sie sagt, was sie gesehen hat, und überlässt die Entscheidung einem Menschen. Diese Grenze halte ich absichtlich: Ein Monitor, der einmal falsch liegt und nur redet, kostet nichts. Ein Monitor, der einmal falsch liegt und handelt, kostet einen Tag Umsatz in die andere Richtung. Jede Nachricht endet mit dem Wort ADVISORY, damit niemand sie für eine bereits ausgeführte Aktion hält.

Kleinigkeiten, die sich als wichtig herausgestellt haben

Der Timeout muss kürzer sein als das Cron-Intervall, sonst stapeln sich die Läufe. Der User-Agent muss wie ein Browser aussehen, sonst liefern manche Hoster eine leichtere Seite ohne den Knopf aus. Die Zeichenkette muss etwas sein, das ein Mensch vermissen würde, wenn es fehlt, kein Kommentar im HTML, den ein Redesign entfernen kann, ohne dass es jemand merkt. Und die Zustandsdatei muss einen Neustart überleben, also liegt sie auf der Platte, nicht im Speicher.

Das Ganze sind etwa sechzig Zeilen. Es hat in zwei Monaten viermal gefeuert, dreimal echt, und der eine Fehlalarm war ein Redesign, das den Knopf umbenannt hat, was ebenfalls eine berechtigte Nachricht ist.