PagerDuty: Verzögerte Benachrichtigungen an Kunden

Unternehmen und Produkt

PagerDuty ist eine cloudbasierte Incident-Management- und Operations-Plattform, die von Engineering-, SRE- und On-Call-Teams genutzt wird, um Produktionsprobleme zu erkennen, zu triagieren und zu beheben. Hauptanwendungen sind Echtzeit-Event-Ingestion, intelligentes Routing und Multi-Channel Alert-Zustellung – integriert in Monitoring-, CI/CD- und Kollaborationstools. Die Plattform koordiniert Dienstpläne, Eskalationen, Runbooks und die Kommunikation mit den Beteiligten, um die MTTA/MTTR für Unternehmenskunden in großem Maßstab zu reduzieren. PagerDuty ist ein direkter Wettbewerber von ilert, weshalb Erkenntnisse aus diesem Incident für uns und unsere Community besonders wichtig sind.

Was genau ist vorgefallen?

Eine neue API-Logging-Funktion enthielt einen Bug, der für jede API-Anfrage einen neuen Kafka-Producer erzeugte, anstatt einen vorhandenen wiederzuverwenden. Das überflutete Kafka mit Millionen Producer-Verbindungen pro Stunde, überlastete den Speicher der Broker und destabilisierte den Cluster. Dadurch kam es zu Folgeausfällen in abhängigen Services.

‍

Das Ergebnis: verzögerte Benachrichtigungen an Kunden sowie intermittierende API-Fehler (Timeouts und 5xx). Bei Webhooks und Chat-Integrationen wie Slack und Microsoft Teams kam es ebenfalls zu Verzögerungen, und während der Wiederherstellung wurden einige Benachrichtigungen dupliziert. Incident-Erstellung und -Updates verlangsamten sich, Eskalationen dauerten länger, und Status-Updates trafen gelegentlich verspätet ein. Akzeptierte Daten gingen nicht verloren, jedoch führten Backlogs zu erhöhten MTTA und MTTR – mit den größten Auswirkungen in der US-Region.

Timeline

28.08.2025. 03:53 UTC (Beginn des ersten Incidents) → 10:10 UTC (vollständig behoben)

TTD: nicht veröffentlicht.

TTR: 6 h 17 min.

‍

28.08.2025. 16:38 UTC (Beginn des zweiten Incidents) → ~17:28 UTC (Auswirkung deutlich mitigiert) → 20:24 UTC (vollständig behoben)

TTD: nicht veröffentlicht.

TTR: 3 h 46 min (16:38 → 20:24). Das Team konnte die Auswirkungen auf Kunden innerhalb von ca. 50 Minuten begrenzen und den Service bis 20:24 vollständig wiederherstellen.

Wer war betroffen?

Kunden in den US-Service-Regionen erlebten degradierte Event-Ingestion und API-Fehler; ausgehende Benachrichtigungen, Webhooks, Chat-Integrationen (Slack und Microsoft Teams) und die REST API waren intermittierend beeinträchtigt. Zuvor akzeptierte Daten gingen nicht verloren; Backlogs verursachten jedoch Verzögerungen und einige doppelte Webhooks während des Aufholprozesses.

So reagierte PagerDuty

Zur Stabilisierung fokussierte sich das Team zunächst auf Kafka. Es wurde Kapazität hinzugefügt, ein problematischer Broker aus dem Service genommen und der verfügbare Speicher der verbleibenden Broker erhöht. Diese Änderungen erfolgten per Rolling Restarts, sodass der Cluster nie vollständig offline war. Der zusätzliche Headroom reduzierte den Memory-Druck und ermöglichte Kafka, den Traffic wieder zu verarbeiten, während die Untersuchung des Incidents weiterging.

‍

Anschließend untersuchte das Team den ungewöhnlichen Anstieg der Kafka-Producer-Aktivität. Als es später am Tag zu einer Wiederholung kam, war das Signal klar: Eine kürzlich eingeführte API-Nutzungs-/Auditing-Funktion startete für jede Anfrage einen neuen Producer. Das Team deaktivierte die Funktion und rollte sie schnell zurück. Dadurch wurde die Producer-Flut an der Quelle eliminiert und die Producer-Metadata-Last im Cluster stabilisiert.

‍

Nachdem die Ursache behoben war, lag der Fokus auf der Recovery. Backlogs in Queues und nachgelagerten Services wurden kontrolliert abgebaut, um sekundäre Spitzen zu vermeiden. Von Kafka abhängige Systeme (APIs, Webhooks und Chat-Integrationen) wurden geprüft, und während des Aufhol-Prozesses entstandene doppelte Benachrichtigungen wurden eingegrenzt. Erst nach End-to-End-Checks und wiederhergestellten Normal-Latenzen erklärte das Team den Incident als vollständig gelöst.

So kommunizierte PagerDuty

Eine Publishing-Abhängigkeit blockierte zunächst automatische Status-Seiten-Updates.

‍

Das PagerDuty-Team ging auf einen manuellen Aktualisierungspfad über, entfernte später die Abhängigkeit, veröffentlichte das manuelle Runbook erneut und verpflichtete sich zu häufigeren Live-Drills für Status-Kommunikation.

Wichtigste Learnings für andere Unternehmen

• Guardrails für Producer-/Client-Lebenszyklen. Verwenden Sie einen langlebigen Kafka-Producer pro Service-Instanz und legen Sie dies als feste Regel im Code fest. Fügen Sie einfache Prüfungen in CI hinzu, die den Build fehlschlagen lassen, wenn pro Anfrage oder in anderen Hot Paths ein neuer Produzent erstellt wird. Fügen Sie eine kleine „Frühwarnung“ in der Staging-Umgebung und am Rand der Produktion hinzu, die die Anzahl der Producer nach jeder Bereitstellung überwacht. Wenn diese sprunghaft ansteigt, wird das Rollout automatisch gestoppt.
• Die richtigen Kapazitäts-Signale beobachten. Behandeln Sie die Integrität der Broker-Metadaten und den freien Speicherplatz als SLOs mit Top-Priorität und nicht als nette “nice-to-have”-Diagramme. Überwachen Sie die aktive Producer-Anzahl, Broker-Heap-Nutzung, Controller-Queue-Tiefe und Producer-ID-Ablauf. Alarmieren Sie bei plötzlichen Sprüngen im Zusammenhang mit einem Release – diese Änderungen sind oft das erste Warnsignal, noch bevor Fehlerraten steigen.
• Progressive Auslieferung mit Auto-Rollback. Koppeln Sie Feature Flags an objektive Guardrails: API-5xx-Rate, Enqueue-Latenz, Broker-Heap-Headroom und Backlog-Wachstum. Erhöhen Sie den Traffic schrittweise (z. B. 1 % → 5 % → 25 % → 50 %), und lassen Sie die Automatisierung das Flag sofort zurückrollen, sobald eine Begrenzung überschritten wird. So entfällt die Verzögerung durch „Human-in-the-Loop“, wenn Sekunden zählen.
• Eingrenzung des Blast-Radius. Gestalten Sie die Einführung so, dass ein problematisches Feature nicht die gesamte Pipeline lahmlegt. Nutzen Sie separate Kafka-Cluster oder Namespaces für experimentelle/Low-Trust-Features, wenden Sie Backpressure an Service-Grenzen an und fügen Sie Circuit Breaker hinzu, die auslösen, bevor der Shared Bus überlastet wird. Bevorzugen Sie asynchrone Retries mit Jitter, um synchronisierte Stürme während der Wiederherstellung zu vermeiden.
• Playbooks für kaskadierende Ausfälle. Legen Sie vorab die Schritte fest, die Sie befolgen, wenn es kritisch wird: wie wird ein Broker-Heap sicher erhöht, ein verdächtiger Broker rotiert oder drainiert, Partitionen erhöht oder bestimmte Producer pausiert. Halten Sie One-Click-Runbooks für Rolling Restarts Kafka-abhängiger Services bereit und üben Sie diese in Game Days, damit der Ablauf sich fest einprägt – und nicht improvisiert wird.
• Resiliente Outage-Kommunikation. Sorgen Sie dafür, dass die Statusseite veröffentlicht, selbst wenn vorgelagerte Systeme beeinträchtigt sind. Entfernen Sie fragile Abhängigkeiten aus dem Publishing-Pfad, halten Sie eine verifizierte manuelle Post-Methode bereit und proben Sie diese vierteljährlich. Bereiten Sie externe Templates vor („Degradation“, „Delays“, „Duplicate Notifications“), damit Updates schnell und konsistent veröffentlicht werden, während Ihr Engineering die Plattform stabilisiert.

Das Wichtigste kurz zusammengefasst

Die Störung ging auf ein fehlerhaftes Feature zurück, das bei jeder API-Anfrage einen neuen Kafka Producer erzeugte – mit Spitzen von rund 4,2 Millionen zusätzlichen Producern pro Stunde. Das erschöpfte den Broker-Heap und löste eine kaskadierende Störung im Cluster aus.

‍

Kunden erlebten zurückgewiesene oder verzögerte Events, degradierte REST-Endpoints, verlangsamte Webhooks und Chat-Integrationen sowie doppelte Benachrichtigungen während des Aufholprozesses – akzeptierte Daten gingen jedoch nicht verloren. Das Team stabilisierte die Plattform durch Erhöhung des Broker-Heaps und Rolling Restarts und verhinderte ein Wiederauftreten durch das Zurückrollen des fehlerhaften Features. In der Frühphase des Incidents schlugen automatisierte Status-Updates fehl, daher wechselte das Team auf einen manuellen Pfad und beseitigte später die Abhängigkeit, um die Kommunikation zu stärken.

So kann ilert unterstützen

• Halten Sie Benachrichtigungen sicher – auf einer geschützten, eigenständigen Ebene in ilert. Wenn Sie als Incident-Response-Anbieter Ihr eigenes Produkt für Alarmierung nutzen, fügen Sie eine letzte Sicherheitsstufe hinzu, indem Sie ilert verwenden.
• Nutzen Sie verschiedene Kommunikationskanäle sowie eine Notfall-Hotline. Senden Sie jede Alarmierung über mehrere Pfade – App-Push, Telefonanruf, SMS, E-Mail und Chat-Tool – über mehrere Provider. Versuchen Sie es weiter, bis jemand reagiert. Fügen Sie eine Notfall-Hotline hinzu, die das Bereitschaftsteam direkt anruft, wenn andere Pfade nicht funktionieren.
• Status-Kommunikation ohne Abhängigkeit von instabilen Verbindungen. Automatisieren Sie Stakeholder- und Statusseiten-Updates über ilerts Alert Actions, behalten Sie jedoch einen verifizierten manuellen Publikationsmodus bei. Das lernen wir aus dem PagerDuty-Incident, bei dem eine Publishing-Abhängigkeit frühe Updates blockierte.
• Guardrails, gekoppelt an Deployments und Feature Flags. Die Root Cause war ein Feature, das die Producer-Kardinalität explodieren ließ. Verbinden Sie ilert mit CI/CD und Feature Flags, um Deploy-SLOs (Enqueue-Latenz, 5xx-Rate, Backlog-Wachstum) zu überwachen und bei Schwellenverletzung zu eskalieren oder ein Rollback auszulösen.
• Postmortems, die Erkenntnisse in Handlungen umsetzen. Erstellen Sie ein strukturiertes Postmortem, weisen Sie Korrekturmaßnahmen zu (z. B. Producer-Lifecycle-Linting, Metadata-SLOs, Härtung der Status-Kommunikation) und verfolgen Sie diese bis zum Abschluss, damit Fixes nicht im Sand verlaufen.