Kurz vor Mitternacht pazifischer Zeit am 19. Oktober 2025 führte eine Race Condition in der DNS-Automatisierung von Amazon DynamoDB dazu, dass der regionale Endpunkt des Dienstes in us-east-1 einen leeren DNS-Eintrag erhielt. Alle Systeme, die in dieser Region auf DynamoDB angewiesen waren, begannen auszufallen, und der Ausfall kaskadierte auf weitere abhängige AWS-Dienste. Laut offizieller Zusammenfassung von AWS dauerte der Vorfall rund vierzehneinhalb Stunden an.
Zahlreiche Teams verfügten an diesem Morgen über vollkommen gesunde Server. Ihre Uptime-Monitore blieben durchgehend grün, während ihr Authentifizierungsdienst, Zahlungsanbieter oder E-Mail-Dienstleister kollabierten. Die meisten Störungen sind jedoch kleiner: Ihr E-Mail-Provider verzögert den Versand um vierzig Minuten, der Support ertrinkt in Tickets nach dem Motto „Mein Link zum Passwort-Zurücksetzen kommt nicht an“, und irgendwann entdeckt jemand die Statusseite des Anbieters, auf der seit einer halben Stunde „Eingeschränkte Leistung“ steht.
Ich arbeite bei Page Deltas – einem Tool, das öffentliche Webseiten beobachtet und Sie alarmiert, wenn sich dort etwas nach Ihren Vorgaben verändert; behalten Sie das im Hinterkopf, wenn ich es unten mit anderen Ansätzen vergleiche. Dieser Beitrag zeigt Ihnen, wie Sie das Tool auf die Statusseiten Ihrer wichtigsten Drittanbieter richten: welche URL Sie wählen, wie Sie ein Briefing verfassen, das störendes Rauschen ignoriert, wohin die Benachrichtigungen gesendet werden sollten und wo die Grenzen dieses Setups liegen.
Warum Ihr internes Monitoring grün bleibt
Ihr Uptime-Monitor fragt lediglich ab, ob Ihre eigene Website antwortet – und während des Ausfalls eines Drittanbieters tut sie das in aller Regel fehlerfrei. Ihr APM wird zwar einen starken Anstieg von Fehlern bei ausgehenden Aufrufen an den Anbieter registrieren, kann Ihnen jedoch nicht sagen, ob die Ursache in Ihrem eigenen Code oder in der externen Infrastruktur liegt. Genau diese Frage beantwortet eine Statusseite, und die Antwort verändert Ihre unmittelbaren Schritte: Sie machen nicht voreilig das Deployment von vor einer Stunde rückgängig; Sie teilen dem Support mit, dass ein bekannter externer Ausfall vorliegt, und prüfen, ob Sie Ihre eigene Statusseite aktualisieren sollten.
Warum also nicht einfach direkt auf der Seite des Anbieters abonnieren? Das sollten Sie tun, wenn es Ihren Bedarf abdeckt. Viele Statusseiten basieren auf Atlassian Statuspage und bieten Benachrichtigungen per E-Mail, SMS, Slack, Teams oder Webhook an – je nachdem, was der Anbieter freigeschaltet hat. Die Schwierigkeiten beginnen beim achten Anbieter: Jedes Abonnement ist eine separate Einrichtung, die häufig im Postfach einer einzelnen Person versandet, jeder Anbieter formatiert seine Nachrichten anders, und ein Filtern auf die tatsächlich genutzten Komponenten wird nicht immer unterstützt. Manche Anbieter betreiben sogar selbstgebaute Seiten ganz ohne Abo-Button.
Ein Web-Änderungsmonitor bietet Ihnen einen einheitlichen Weg für alle Anbieter: Sie fügen die URL der Statusseite ein, beschreiben in einem Satz, was Sie interessiert, und jeder Alarm trifft im selben Kanal im identischen Format ein.
Welche Seiten sollten Sie beobachten?
Wählen Sie die Seite, die den aktuellen Zustand in Echtzeit anzeigt – meist status.anbieter.com. Wählen Sie nicht die allgemeine Unternehmens-Startseite oder eine Marketingseite zum Thema Zuverlässigkeit. Die meisten SaaS-Statusseiten teilen denselben Aufbau: eine Komponentenliste mit Zustandsangaben, ein Banner für laufende Vorfälle, anstehende Wartungsfenster und eine Liste kürzlicher Vorfälle mit Link zum Gesamtarchiv.
Beginnen Sie mit den Abhängigkeiten, deren Ausfall Ihre Kunden sofort spüren würden. Für die meisten Softwareteams ist diese Liste überschaubar.
| Abhängigkeit | Was Ihre Kunden bei einem Ausfall bemerken |
|---|---|
| Zahlungsabwicklung | Checkout schlägt fehl oder Verlängerungen schlagen fehl |
| Login und Identität | Niemand kann sich im System anmelden |
| E-Mail- und SMS-Versand | Passwort-Resets und Einladungen kommen nicht an |
| Cloud-Region, CDN oder DNS | Alles reagiert extrem langsam oder ist unerreichbar |
| KI-Modell-APIs | KI-Funktionen laufen in Timeouts oder werfen Fehler |
Wenn Sie nur wenige URLs überwachen können, fangen Sie oben an. Fehler bei Zahlungen oder beim Login führen innerhalb von Minuten zu Support-Tickets, während ein verlangsamtes CDN anfangs vielleicht nur in internen Metriken auffällt. Die 10 URLs des kostenlosen Tarifs decken alle fünf Zeilen ab und lassen noch Spielraum für die unten genannten Ergänzungen.
Zwei weitere Seiten sind nützlich. Die Archivseite (oft /history) ist ein hervorragender Zweitmonitor für kritische Anbieter: Ein kurzer Vorfall kann zwischen zwei Prüfungen der Hauptseite beginnen und behoben werden, bleibt im Verlauf jedoch gelistet – so erfahren Sie verlässlich, wenn auch etwas später, davon. Während eines längeren Vorfalls können Sie auch die spezifische Detailseite der Störung als temporären Monitor anlegen, um jedes Update mitzubekommen. Löschen Sie ihn nach Behebung wieder, damit er Ihr Kontingent nicht dauerhaft belegt.
Einrichtung Schritt für Schritt
Die Einrichtung dauert etwa fünf Minuten und folgt demselben Schema wie unser Leitfaden zur Changelog-Überwachung, mit einem angepassten Briefing.
1. Konto anlegen und Kanal einrichten
Registrieren Sie sich kostenlos, öffnen Sie Kanäle und legen Sie das Ziel für Ihre Benachrichtigungen fest. Ich empfehle einen eigenen Kanal wie #vendor-status statt #engineering, wo wichtige Meldungen leicht untergehen. Slack, Discord und Microsoft Teams arbeiten mit einer Incoming-Webhook-URL. In Teams klicken Sie mit der rechten Maustaste auf den Kanal, wählen Connectors, dann Eingehender Webhook, Konfigurieren und fügen die URL in Page Deltas ein. Bei E-Mail muss der Empfänger zunächst eine Bestätigungsnachricht verifizieren. Klicken Sie bei jedem Kanal auf Test senden, um die Zustellung abzusichern.
2. Monitor mit einem Briefing hinzufügen
Klicken Sie auf Neuer Monitor und fügen Sie die URL der Statusseite ein. Beschränken Sie sich auf einen Anbieter pro Monitor, damit das Briefing exakt dessen Komponenten benennen kann. Wenn verschiedene Teams für unterschiedliche Dienste zuständig sind, verknüpfen Sie pro Monitor einen eigenen Kanal.
Statusseiten verändern sich häufiger, als man denkt – selbst an ruhigen Tagen: Uptime-Prozentsätze schwanken leicht, Zeitstempel der letzten Aktualisierung ändern sich, und die Liste jüngster Vorfälle rückt jeden Tag um eine Zeile mit „Keine Vorfälle gemeldet“ weiter. Geplante Wartungen werden Wochen im Voraus angekündigt. Ein gewöhnliches Diff-Tool würde bei all diesen Kleinigkeiten unnötig Alarm schlagen.
Die Beschreibung des Monitors dient unserem LLM als Prompt, um zu beurteilen, ob eine Änderung relevant ist. Schreiben Sie sie wie eine Anweisung an einen Kollegen, der die Seite für Sie im Auge behält. Für einen E-Mail-Dienstleister funktioniert folgende Formulierung hervorragend:
Statusseite unseres E-Mail-Providers. Wir nutzen ausschließlich die Komponenten
Email API und Webhooks in der Region US.
Benachrichtige mich, wenn ein neuer Vorfall gemeldet wird, der diese Komponenten
oder diese Region betrifft, wenn sich Status oder Schweregrad ändern oder wenn er gelöst ist.
Benachrichtige mich, wenn eine der beiden Komponenten den Zustand Operational verlässt.
Ignoriere Uptime-Prozentsätze, Zeitstempel der letzten Aktualisierung, tägliche Zeilen
mit "Keine Vorfälle gemeldet" und Störungen in anderen Regionen.
Erwähne geplante Wartungsarbeiten nur, wenn sie innerhalb von 48 Stunden beginnen.
Fasse betroffene Komponente, aktuellen Status und neuestes Update zusammen.Die Ausschlusszeile leistet den Löwenanteil der Arbeit. Wenn Sie sie weglassen, verbringen Sie die erste Woche damit, um Mitternacht Benachrichtigungen über das Weiterrücken der Vorfallstabelle zu erhalten.
Bei einem großen Cloud-Anbieter sind genaue Regions- und Dienstangaben noch entscheidender. Ein öffentliches Cloud-Dashboard umfasst Hunderte Dienste über Dutzende Regionen, und in einer normalen Woche ist fast immer irgendwo ein Teilbereich beeinträchtigt. Benennen Sie explizit die Regionen und Services, auf denen Ihre Infrastruktur läuft, und fordern Sie Benachrichtigungen ausschließlich für diese an.
3. Ersten Check als Ausgangsbasis nutzen
Ein neu angelegter Monitor führt kurz nach der Erstellung seinen ersten Abruf durch. Dieser Abruf speichert den Ausgangszustand, sodass Sie in der ersten Minute keinen Fehlalarm erhalten, es sei denn, die Seite verändert sich zwischen zwei Prüfungen. Öffnen Sie den Monitor anschließend und prüfen Sie den Screenshot, um sicherzugehen, dass die erwarteten Komponenten erfasst wurden.
4. Bei Verdacht sofort prüfen
In Page Deltas legen Sie kein starres Abrufintervall fest. Der Zeitplan ist adaptiv: Häufig veränderte Seiten werden öfter geprüft, und bezahlte Tarife haben bei voller Warteschlange Vorrang. Da eine Statusseite die meiste Zeit ruhig bleibt, klicken Sie bei steigenden Fehlerraten und Verdacht auf einen Anbieter direkt auf Jetzt prüfen. Dieselbe Aktion ist auch über die API verfügbar (limitiert auf einmal pro Minute je Monitor):
curl -X POST \
-H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-nowWas tun, wenn ein Alarm eintrifft
Sobald eine Änderung Ihrem Briefing entspricht, erhalten Sie eine Benachrichtigung mit einer Zusammenfassung in klarer Sprache sowie Vorher- und Nachher-Screenshots. Wenn Sie den signierten Webhook nutzen, sieht der Payload folgendermaßen aus (Werte sind für das Beispiel simuliert):
{
"event": "change.detected",
"monitor_id": "01HX7Q...",
"monitor_url": "https://status.example-mail.com/",
"monitor_name": "Status E-Mail-Provider",
"change_id": "...",
"detected_at": "2026-10-14T07:21:00Z",
"summary": "Neuer Vorfall: Verzögerte E-Mail-Zustellung in Region US. Email API wechselte von Operational auf Degraded Performance. Status: Investigating.",
"before_screenshot_url": "https://.../before.png",
"after_screenshot_url": "https://.../after.png",
"dashboard_url": "https://app.pagedeltas.com/monitors/..."
}Die erste Person, die den Alarm sieht, sollte im Thread kurz festhalten, was das für den eigenen Dienst bedeutet. Der Support kann eine Notiz zu einem bekannten externen Vorfall anheften, bevor sich Tickets stapeln. Der diensthabende Ingenieur kann aufhören, ein unschuldiges Deployment zu untersuchen, und falls der Ausfall Endnutzer betrifft, aktualisieren Sie Ihre eigene Statusseite, damit Kunden es zuerst von Ihnen erfahren.
Arbeitet Ihr Team mit PagerDuty oder einem ähnlichen Vorfall-Management-System, kann der signierte Webhook dieses über eine kleine Relay-Funktion speisen. Da unser Payload nicht dem nativen PagerDuty-Format entspricht, genügen wenige Zeilen serverloser Code, um die Signatur zu verifizieren und das Event weiterzuleiten:
import crypto from "node:crypto";
export async function handle(rawBody, signature) {
const expected = "sha256=" + crypto
.createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
.update(rawBody).digest("hex");
if (signature.length !== expected.length ||
!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
return 401;
}
const alert = JSON.parse(rawBody);
await fetch("https://events.pagerduty.com/v2/enqueue", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
routing_key: process.env.PAGERDUTY_ROUTING_KEY,
event_action: "trigger",
dedup_key: alert.change_id,
payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
}),
});
return 200;
}Hashen Sie den Roh-Body, bevor Sie ihn parsen, da die Signatur sonst fehlschlägt. Die Kanal-Dokumentation erläutert alle Einzelheiten. Jeder Alarm wird pro Kanal einmal ohne automatische Wiederholung zugestellt: Bei unverzichtbaren Anbietern empfiehlt sich ein zweiter Kanal eines anderen Typs (etwa Slack plus E-Mail), falls Slack oder das Relay vorübergehend streiken.
Grenzen dieses Ansatzes
Dieses Setup spiegelt wider, was ein Drittanbieter offiziell veröffentlicht – und das bringt gewisse Einschränkungen mit sich, die Sie kennen sollten.
Anbieter melden Ausfälle oft erst mit Verzögerung. Ihre internen Fehlergraphen zeigen Probleme mitunter an, bevor die Statusseite überhaupt reagiert: Betrachten Sie den Alarm daher eher als Bestätigung denn als erste Frühwarnung. Zudem ersetzt dies weder synthetische Prüfungen noch das Uptime-Monitoring Ihrer eigenen API: Letztere sagen Ihnen, dass Ihr Produkt defekt ist; die Statusseite erklärt Ihnen den Grund.
Zwischen den Abrufen wird eine Änderung beim nächsten geplanten Lauf erfasst, ohne dass es ein garantiertes Minutentakt-Intervall gibt. Für jene ein oder zwei Anbieter, bei denen jede Minute zählt, empfiehlt es sich, das anbietereigene Abonnement beizubehalten und Page Deltas für den Rest zu nutzen. Zudem erfassen wir nur öffentliche Seiten: Ein Status, der nur innerhalb einer internen Admin-Konsole sichtbar ist, bleibt vorerst unerreichbar.
Wir vergleichen den Text der Seite. Wenn ein Anbieter einen Ausfall ausschließlich über einen farbigen Punkt ohne Textveränderung darstellt, wird dies nicht erkannt. Visualping erlaubt die Überwachung eines Pixelbereichs und ist in diesem Sonderfall besser geeignet. Wenn die Statusseite selbst offline geht, schlagen die Prüfungen fehl, anstatt einen Alarm auszulösen; nach 10 aufeinanderfolgenden Fehlern pausiert sich der Monitor und Ihre Administratoren erhalten eine Benachrichtigung.
Mit drei Anbietern starten
Wählen Sie die drei Anbieter aus, deren Ausfall Ihnen am meisten schaden würde – typischerweise Zahlungen, Login und E-Mail. Fügen Sie die URLs ihrer Statusseiten ein, passen Sie das obige Briefing mit Ihren Komponenten und Regionen an und senden Sie einen Testalarm an #vendor-status. Der kostenlose Tarif deckt 10 URLs mit KI-Filterung, sämtliche Alarmkanäle und API-Zugriff ab – ganz ohne Kreditkarte. Kostenlos mit der Überwachung beginnen.
Julien, Produktmanager bei Page Deltas