Cases4 cases
1 to 4 of 4
- Symptoms
For about two weeks in August 2026, some PyPI users got intermittent 502 and 503 errors when downloading files from files.pythonhosted.org, and installations from PyPI failed. The first two reports of persistent 502s were opened in the support tracker on 17 August.
- Trigger
A partial rollback during a canary deployment inside Fastly's network, whose canary cohort had included PyPI's traffic for a number of years, left the caching configuration of one Seattle point of presence reverted while the routing configuration in front of it was not.
- Root cause
- Component
- Contributing factor
- Detection
Users filed reports in the PyPI support tracker; one report isolated the 502s to a single Fastly cache node using the x-served-by headers of the failing responses.
- Remediation
- Fastly's network operations removed the routing override that sent part of PyPI's traffic to the affected point of presence
- Fixed the B2-to-S3 fallback for the case where B2 does not respond at all (infra#237)
- Exempted suffix and multi-range requests from segmented caching (infra#241, infra#243)
- Fastly patched the canary configuration bug and removed all PSF traffic from its canary cohort
- Moved the segmented-caching exemption check after URL normalization (infra#245)
- Action items
- Improve the logging configuration of the file hosting service (infra#238)
- Reject HTTP methods that a file host should not receive (infra#239)
- Follow a support ticket with Fastly about segmented-caching range handling, and revert PyPI's own handling code once Fastly fixes it
- Return to Fastly's canary program once clearer controls and notifications exist around that traffic
- Hire an infrastructure engineer, partly for PyPI, to catch conditions like this earlier
- Lessons
None of the PyPI configuration bugs were new; they had been in the configuration for a while and came out only when real traffic on large files with range requests forced an investigation. The 5xx baseline was already noisy, so the start of the Fastly problem was easy to miss, and part of that noise turned out to be one of the bugs.
IL-0214PagerDuty's Kafka brokers ran out of JVM heap one after another, and the event APIs rejected events with 502 responsesPagerDuty2025- 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.
- 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
- Component
- Contributing factor
- 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.
- Symptoms
On 2025-03-12 from 10:58 UTC, alerts for high backend response times came in, and the MediaWiki deployments mw-api-int, mw-parsoid and mw-jobrunner, which serve MediaWiki for non-user-facing purposes, showed high latency and database errors. The External Storage cluster, whose hosts store the compressed text of wiki page revisions, had a sharp rise in load and connections. The same happened again on 2025-03-13 from 11:15 UTC.
- Trigger
At 10:44 UTC on 12 March a Scap deployment of the PHP 8.1 rollout for mw-api-int, mw-parsoid and mw-jobrunner was run with the flag -Dbuild_mw_container_image:False; the rollout was deployed with Scap again at 11:15 UTC on 13 March.
- Root cause
- Component
- Contributing factor
- Detection
Alerts for high backend response times started at 10:58 UTC on 12 March, 14 minutes after the Scap deployment; 2 on-call engineers were paged. The MediaWikiMemcachedHighErrorRate alert that pointed at the cause fired only briefly because its log pipeline was overloaded.
- Remediation
- Deployed a patch to cirrus-streaming-updater that reduced SUP parallelism
- Reduced the concurrency of the categoryMembershipChange job in changeprop-jobqueue
- On 12 March, reverted 1126607 and 1126650 and re-ran Scap
- On 13 March, rolling-restarted changeprop-jobqueue
- Rolling-restarted mw-api-int
- Disabled the categorymembership job in changeprop-jobqueue
- Reverted 1127476 and 1127478
- Redeployed mw-api-int to pick up the revert
- Increased the number of mw-api-int replicas
- Redeployed mw-jobrunner to pick up the revert
- Redeployed mw-parsoid to pick up the revert
- Action items
- Reduce the number of messages sent through channel:Memcached during failures
- Add helm rollback functionality to Scap
- Decide whether Scap should update helmfile-defaults when -Dbuild_mw_container_image:False is set
- Consider removing envvars.inc from MediaWiki images
- Consider "Why" dashboards that give an overview of a group of related components together with relevant links to follow
- Coordinate incident responders better
- Be able to work with MediaWiki developers during incidents
- Lessons
The write-up puts the weight not on the technical root cause but on why the team could not see, even after the 12 March incident, that three MediaWiki deployments were running without Memcached. Alert dashboards showed what was happening, such as many busy PHP workers, but not why; dashboards linking components that affect each other, such as SQLBlobStore keys and External Storage, would have helped. The alert that pointed in the right direction did not stay firing and would probably have been lost among 78 others. The incident coordinator could not tell who was working on what or who had joined or left, the channels were noisy, the external impact was judged more critical than it was, and trace.wikimedia.org was not used although it might have helped.
- Symptoms
From 12:47 AM PDT on 21 April 2011, a subset of Amazon EBS volumes in one Availability Zone of the US East Region could no longer serve reads or writes, and EC2 instances that tried to use them got stuck as well. AWS called these "stuck" volumes. EBS API calls across the whole US East Region also returned high error rates and latencies during two periods on the first day.
- Trigger
During a routine network change to upgrade the capacity of the primary EBS network in one Availability Zone, traffic was to be shifted off one of the redundant routers. The shift was executed incorrectly and sent the traffic onto the lower-capacity replication network instead of the other primary router, which could not carry it.
- Root cause
- Component
- Contributing factor
- Remediation
- Rolled back the incorrect traffic shift, which restored network connectivity
- Disabled all new Create Volume requests in the affected Availability Zone at 2:40 AM PDT
- Disabled all communication between the degraded EBS cluster and the EBS control plane from 8:20 AM PDT
- Stopped EBS servers in the degraded cluster from futilely contacting other servers for free space
- Changed the EBS control plane so new EBS-backed instance launches stopped failing
- Moved spare server capacity physically from across the US East Region into the degraded cluster
- Adjusted the negotiation throttles so the new servers could join without flooding the old ones
- Built a separate EBS control plane partitioned to the affected zone and finer-grained throttles, then processed the backlog
- Restored the remaining volumes from S3 snapshots taken early in the event
- Restored volumes on failed machines that had no snapshot after forensic work
- Intervened by hand on the RDS multi-AZ instances that did not fail over automatically
- Action items
- Audit the change process and add automation to prevent the traffic shift mistake
- Change capacity planning and alarming to keep the extra safety capacity needed for large recovery events
- Change the retry logic in EBS nodes to back off harder and reconnect to previous replicas instead of searching for new nodes
- Test and deploy the fix for the race condition that crashed EBS nodes
- Fix the RDS bug that kept multi-AZ instances from failing over automatically
- Improve the EBS control plane timeout logic to prevent thread exhaustion when one zone's cluster is slow
- Make the EBS control plane aware of Availability Zones so it sheds load when over capacity
- Move more EBS control plane functions into per-cluster services that run in the same zone as the cluster
- Offer multiple Availability Zones to Amazon VPC customers
- Provide better tools for building multi-AZ applications that survive the loss of a zone
- Host free webinars and publish whitepapers on fault-tolerant architecture
- Build the fine-grained control and throttling used in recovery into the EBS nodes and automate the recovery models
- Look at changes that keep volumes working while a cluster is degraded, including the ability to take a snapshot of a stuck volume
- Send more frequent and detailed customer updates and staff developer support more widely during events
- Develop tools that show through the APIs whether instances are impaired
- Lessons
AWS writes that with more spare capacity the cluster would have absorbed the re-mirroring requests without a storm, and that it now understands how much capacity large recovery events need. The event also showed that the EBS control plane let a failure in one Availability Zone affect the others, so more work is needed to make zones behave as if completely independent. AWS adds that some customers had critical components in a single zone, and that multi-AZ deployments need to become easier to design and run.
These 4 cases involve Database and Cloud block storage. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.
By root cause3
Dependency failure1 case
- Component
- Contributing factor
- Organisation
Faulty deployment2 cases
- Contributing factor
- Organisation
Operator error1 case
- Component
- Contributing factor
- Organisation