Oh Dear Alternative aus Deutschland

Warum rechnet Oh Dear je Website ab?

Weil das die Größe ist, in der seine Zielgruppe denkt. Agenturen, Freiberufler und Studios betreuen eine zählbare Menge von Kundenseiten, und jede davon ist eine abgeschlossene Einheit mit eigener Domain, eigenem Zertifikat, eigener Sitemap und eigener Rechnung an den Kunden. 15 € für zwei Websites, 49 € für zehn, 99 € für fünfundzwanzig — diese Staffelung lässt sich ohne Umrechnung an einen Kunden weitergeben.

Bemerkenswert ist, was in dieser Staffelung nicht vorkommt: eine Funktionsstaffelung. Jeder Tarif enthält sämtliche Prüfarten, und Teammitglieder sind in jedem Tarif unbegrenzt. Das ist ungewöhnlich und angenehm, weil es die häufigste Reibung in Preisverhandlungen entfernt — niemand muss abwägen, ob eine einzelne Funktion einen Tarifsprung wert ist.

Die Größe passt genau so lange, wie „Website“ die richtige Einheit ist. Sie hört auf zu passen, sobald hinter einer einzigen Domain viele einzeln zu überwachende Dinge stehen: eine Programmierschnittstelle, ein Zahlungsdienst, eine Warteschlange, drei Hintergrunddienste, eine Datenbank, ein Objektspeicher. Aus Sicht einer Abrechnung je Website ist das eine Einheit. Aus Sicht des Betriebs sind es acht, die einzeln ausfallen und einzeln kommuniziert werden müssen.

Daraus ergibt sich eine einfache Prüffrage vor der Entscheidung: Zählt man in der eigenen Organisation Websites oder Dienste? Wer auf die Frage „wie viele überwacht ihr?“ mit einer Zahl antwortet, die der Zahl der Domains entspricht, ist bei einer Abrechnung je Website richtig. Wer eine deutlich größere Zahl nennt, nicht.

Ein Grenzfall verdient Erwähnung: der Dienstleister, der sowohl Websites betreut als auch eigene Infrastruktur betreibt. Hier ist die Antwort meistens beides, und der Versuch, alles in eine Abrechnungsgröße zu pressen, macht eine der beiden Seiten teuer.

Wann ist ein defekter Link ein Vorfall?

Praktisch nie. Ein toter Verweis hat keine Dringlichkeit, keine Dauer und keine betroffene Nutzerschaft im Sinne eines Ausfalls. Er gehört in einen Bericht, den jemand am Dienstagmorgen durchgeht, nicht in einen Kanal, der jemanden weckt. Diese Unterscheidung sauber zu ziehen, ist die wichtigste Einstellung bei jedem Werkzeug, das Qualität und Verfügbarkeit gemeinsam prüft.

Der Grund ist Gewöhnung. Alarmierung funktioniert nur, solange sie selten ist. Ein Kanal, in dem täglich Meldungen über Lighthouse-Werte und tote Links erscheinen, wird nach zwei Wochen nicht mehr gelesen — und ab dann fällt auch die Meldung über den echten Ausfall nicht mehr auf. Der Schaden entsteht nicht durch die einzelne unwichtige Nachricht, sondern durch die Erwartung, dass Nachrichten unwichtig sind.

Die Gegenmaßnahme ist unabhängig vom Anbieter dieselbe: getrennte Wege. Qualitätsbefunde gehen in eine wöchentliche Zusammenfassung oder ein Ticketsystem. Verfügbarkeitsvorfälle gehen in die Rufbereitschaft. Zwischen beiden sollte es keinen gemeinsamen Kanal geben, auch nicht aus Bequemlichkeit.

Es gibt Ausnahmen, und sie sind es wert, benannt zu werden. Ein abgelaufenes TLS-Zertifikat ist ein Qualitätsbefund, der zum Ausfall wird — vierzehn Tage vorher ist es ein Eintrag im Bericht, zwei Tage vorher gehört es in die Bereitschaft. Dasselbe gilt für eine ablaufende Domain. Diese beiden Fälle brauchen eine Eskalation über die Zeit, und die richtet man einmal ein.

Der dritte Fall ist die geplante Aufgabe, die nicht gelaufen ist. Ein ausgefallener nächtlicher Abgleich ist je nach Gegenstand ein Bericht oder ein Vorfall — bei einer Rechnungsstellung eher letzteres. Die Einordnung ist eine fachliche Entscheidung und keine technische, und sie sollte einmal bewusst getroffen und dann festgehalten werden.

Was gehört auf eine Statuspage und was in einen Bericht?

Auf die Statuspage gehört, was Besucher gerade daran hindert, etwas zu tun. In den Bericht gehört alles, was ein internes Qualitätsproblem beschreibt. Ein toter Link auf einer Unterseite gehört nicht auf die Statuspage, auch wenn ein Werkzeug ihn erkannt hat. Ein nicht gelaufener Zahlungsabgleich gehört darauf, auch wenn keine Prüfung ihn gemessen hat.

Die Trennlinie verläuft entlang der Frage, wer die Information braucht. Eine Statuspage hat ein externes Publikum, das sie in genau einem Moment aufsucht: wenn etwas nicht funktioniert. Alles, was diesen Moment nicht betrifft, verdünnt die Seite und macht sie im Ernstfall schwerer lesbar. Eine Seite mit vierzig Komponenten, von denen dreißig Besucher nicht interessieren, beantwortet die eigentliche Frage schlechter als eine mit sechs.

Daraus folgt eine Empfehlung für die Gliederung, die unabhängig vom Werkzeug gilt: Komponenten nach dem benennen, was ein Kunde tun will, nicht nach dem, was technisch existiert. „Anmeldung“, „Zahlung“, „Datei-Upload“ sind gute Komponenten. „api-gateway-eu-west“, „redis-primary“ und „worker-queue-3“ sind es nicht, so korrekt sie technisch auch sein mögen.

Der zweite Punkt betrifft die Richtung. Werkzeuge, die die Statuspage aus Prüfungen ableiten, können nur zeigen, was gemessen wurde. Das ist meistens genug — bis zu dem Tag, an dem ein Vorleister ausfällt, die eigenen Prüfungen grün bleiben und Kunden trotzdem nichts kaufen können. Eine Statuspage, auf der sich nur veröffentlichen lässt, was eine Prüfung gemeldet hat, ist an diesem Tag stumm.

Wie oft muss eine Website auf Qualität geprüft werden?

Deutlich seltener als auf Erreichbarkeit — und der Unterschied ist grundsätzlich, nicht graduell. Eine Verfügbarkeitsprüfung ruft eine Adresse auf und dauert Millisekunden; sie kann jede Minute laufen. Eine Qualitätsprüfung durchläuft die gesamte Website, folgt jedem Verweis und bewertet jede Seite. Das dauert je nach Umfang Minuten bis Stunden und ergibt täglich oder wöchentlich Sinn, nicht minütlich.

Aus dieser Asymmetrie folgt fast alles Weitere. Ein Befund aus einem täglichen Durchlauf ist im Mittel zwölf Stunden alt, wenn ihn jemand liest — das ist für einen toten Link völlig unproblematisch und für einen Ausfall unbrauchbar. Die beiden Prüfarten haben deshalb nicht nur verschiedene Abläufe, sondern verschiedene Zeitbegriffe.

Praktisch heißt das, den Rhythmus nach dem Änderungstempo der Inhalte zu wählen und nicht nach dem Gefühl. Eine Unternehmensseite, die monatlich angefasst wird, braucht keinen täglichen Durchlauf. Ein Nachrichtenangebot mit hundert neuen Beiträgen pro Woche braucht ihn. Ein Onlineshop mit wechselndem Sortiment liegt dazwischen und profitiert eher von einem Durchlauf nach jeder Veröffentlichung als von einem festen Takt.

Der zweite Punkt betrifft die Last auf der geprüften Seite. Ein vollständiger Durchlauf über zehntausend Unterseiten ist ein spürbarer Zugriffsvorgang, der in Auswertungen auftaucht und bei knapp bemessenen Umgebungen die Antwortzeiten beeinflusst. Er gehört deshalb in eine Zeit geringer Nutzung — und nicht in den Vormittag, in dem ohnehin die höchste Last anliegt.

Wer beide Prüfarten parallel betreibt, sollte den Qualitätsdurchlauf zudem so legen, dass er nicht mit einem Wartungsfenster zusammenfällt. Sonst erzeugt eine planmäßige Abschaltung eine Liste von hunderten scheinbar kaputten Verweisen, und der nächste echte Befund geht in dieser Liste unter.