Cases2 cases

1 to 2 of 2

1. IL-0214 PagerDuty's Kafka brokers ran out of JVM heap one after another, and the event APIs rejected events with 502 responses

   PagerDuty2025

   Symptoms

   When a Kafka cluster of PagerDuty's US Service Regions began failing at 03:53 UTC on 28 August 2025, the first alerts pointed to one failing broker. More brokers then ran out of memory, and PagerDuty's event APIs began rejecting incoming events with a response status code of 502 while notifications, webhooks, chat integrations and the REST API degraded.

   Memory pressureHigh error rateThroughput degradation

   Trigger

   A new feature that recorded API key usage in a Kafka topic was being rolled out by configuration: 1% on 21 August, 5% and then 25% on 27 August, and 75% on 28 August. A logical error in the feature created a new Kafka producer for every API request instead of reusing one producer.

   Root cause

   Faulty deployment

   Component

   Message broker

   Contributing factor

   Monitoring blind spotSignal buried in noiseChange with a delayed effectExcessive blast radius

   Detection

   Alerts pointed to one failing Kafka broker at the start of the first incident, and alerts fired again at 16:38 UTC when Kafka performance degraded for the second time. Critical alerts about core API errors were buried among webhook pages.

   Remediation

   • Expanded the Kafka cluster and removed the first failing broker
   • Doubled the Kafka broker heap size and applied it with a rolling restart across the cluster
   • Added status page updates by hand through backup procedures when automated publishing failed
   • Recovered Kafka-dependent services, some by manual intervention, and backfilled lost data with scripts
   • In the second incident, doubled the heap again with another rolling restart
   • Rolled back the API usage feature with a pull request that stopped it from publishing Kafka messages

   Action items

   • Remove the dependency that blocked status page automation and simplify and republish the manual runbook
   • Run live drills regularly so status updates go out even when parts of the platform are degraded
   • Expand JVM and Kafka monitoring of heap, garbage collection and producer and consumer health
   • Strengthen service dependency mapping so cascading failures are easier to trace
   • Collect customer impact metrics into incident workflows automatically
   • Add stricter change management guardrails, with readiness checklists and slower ramp-up windows for major rollouts
   • Improve recovery mechanisms in the streaming systems
   • Automate communication workflows such as status page updates, internal and external syncs and reminders
   • Test major incident workflows monthly with chaos engineering, such as status page failover
   • Define clearer incident severity levels and roles, including dedicated communications liaisons

   Lessons

   PagerDuty found its message processing more intricate than it had thought: some services had to be restarted to pick up changes, some API activity produced far more messages than expected, and it was hard to tell which parts of the system put heavy load on Kafka. Because producers and JVM heap were barely observed, responders could not see the first failure until several downstream systems were affected, and no one on the call held a model of the whole system. Enabling the feature through configuration rather than a separate deployment was meant as a safety step but made the outage harder to link to the change. Runbooks and backfill scripts were imperfect but gave responders a head start, and the second incident was mitigated in about 50 minutes by repeating the first incident's steps.

   View case
2. IL-0362 PagerDuty could not dispatch notifications for 18 minutes when a peering point shared by two AWS regions degraded

   PagerDuty2013sev1

   Symptoms

   On Saturday 13 April 2013 at 8:11am Pacific Time, PagerDuty's on-call engineer was paged about one node of the notification dispatch system, and an attempt at 8:13 to bring the node back failed. Customers saw delayed notifications and 500 errors on PagerDuty's API endpoints.

   High latencyHigh error rateIntermittent connection failures

   Trigger

   At 7:57am Pacific Time, according to AWS, a peering point in Northern California began to degrade, causing connectivity problems for the two AWS regions that PagerDuty used as two of its three datacenters.

   Root cause

   Cloud provider outage

   Component

   Transit gateway or network interconnectCoordination and key-value store

   Contributing factor

   Single point of failureUnverified assumptionMonitoring blind spot

   Detection

   The PagerDuty on-call engineer was paged at 8:11am about an issue with one node of the notification dispatch system, and at 8:18 monitoring detected multiple-provider failures for notifications.

   Remediation

   • Restarted most of the failed coordinator processes by hand
   • The notification dispatch system reached quorum again and processed all queued notifications

   Action items

   • Add more logging and aggregate logs into a single searchable source
   • Add a process watcher that restarts failed coordinator processes automatically
   • Build a dashboard that shows inter-host connectivity
   • Train engineering staff on Cassandra and ZooKeeper
   • Investigate moving off one of the AWS regions to a new hosting provider and datacenter that avoids a single point of failure

   Lessons

   Datacenters chosen to be independent and physically separate can still share a network peering point, and a design built to survive the loss of one datacenter did not survive losing two at once.

   View case

By root cause2