Graph
Cases4 cases
1 to 4 of 4
IL-0366Cloud Storage uploads and writes in us-central1 slowed and failed with HTTP 503 as traffic piled onto a few backendsGoogle Cloud2026- Symptoms
From 04:00 US/Pacific on 8 October 2026, Google Cloud Storage upload and write operations in the us-central1 region became slow and failed. Clients mostly saw HTTP 503 UNAVAILABLE errors on WriteObject operations and client-side timeouts.
- Trigger
A configuration update to the Cloud Storage load balancing layer turned on a traffic sorting optimization that was meant to deal with local capacity constraints. The recurrence on 9 October came from an incomplete rollback of an upload planner feature.
- Root cause
- Component
- Contributing factor
- Detection
Google engineering teams monitoring system telemetry detected the problem at 04:50 US/Pacific on 8 October, 50 minutes after it began.
- Remediation
- Drained traffic from the most overloaded storage backend nodes
- Deployed a configuration change that disabled the traffic sorting optimization
- Rolled back a recent update to the metadata database service
- Redirected traffic and drained affected storage components again during the recurrence
- Fully reverted the load balancing configuration change, restoring capacity-aware routing
- Returned the drained nodes to service once resource use was back to normal
- Action items
- Validate load balancing logic changes in smaller regions before rolling them out to large, highly utilized regions
- Make the storage load balancing enforce capacity constraints so traffic cannot bypass pre-spilling safeguards
- Speed up internal data movement within highly utilized storage cells to absorb temporary load spikes
IL-0240Cloudflare API requests failed and the dashboard slowed for hours after the authentication database lost its replicasCloudflare2020- Symptoms
On 2 November 2020 the Cloudflare API and dashboard were degraded for six hours and 33 minutes. The success rate of API queries dropped at times to 75%, and the dashboard was up to 80 times slower than normal, while Cloudflare's edge network kept working.
- Trigger
At 14:43 UTC a network switch in a control plane data center partly failed: it kept LACP and BGP running but stopped forwarding some packets, and it recovered on its own six minutes later.
- Root cause
- Component
- Contributing factor
- Detection
At 14:43 UTC alerts fired because the misbehaving switch was unreachable to pings. Engineers then saw that the primary authentication database was overwhelmed.
- Remediation
- Shed load from the primary authentication database by slowing SSL certificate pushes to the edge, emails and other features
- Moved API traffic that could use read replicas to the secondary data center by hand
- Sent authentication calls fully back to the primary data center when the dashboard got worse
- Rebuilt the first database replica, which put itself back into service at 21:20 UTC and returned performance to normal
- Ramped the turned-down services back up so asynchronous processing could catch up
- Action items
- Remove the cluster management limitation that requires rebuilding all replicas after a primary is promoted
- Redesign the user sessions system so dashboard traffic can be steered between data centers
- Change the auto-remediation configuration so a database replica is not promoted so quickly
- Tune each system involved to be more resilient to failures of its dependencies
- Lessons
Every system in the chain had redundancy and none failed completely; each only degraded, which made the chain of events much harder to model and foresee. Automating replica promotion so that it could trigger on a minute's notice had been a point of pride, but for at least one database a fast promotion can do more harm than the failure it answers. Most general-purpose cluster managers use Raft or Paxos rather than Byzantine fault tolerant protocols, accepting a rare failure mode in exchange for a protocol that is simpler to implement correctly and debug.
- Symptoms
On 3 June 2014, PagerDuty's notification pipeline performed poorly and some notifications were delayed after the Cassandra cluster behind it became heavily degraded. About 3% of events sent to the integration API could not be received.
- Trigger
On 3 June 2014 the Cassandra background repair process started its normal run on one node of the cluster while other high load was on the cluster; on 4 June the team restarted the postponed repair by hand.
- Root cause
- Component
- Contributing factor
- Remediation
- Reduced the load on the Cassandra cluster
- Stopped the Cassandra repair process
- Cut communication between some Cassandra nodes to stabilise the cluster
- On 4 June, deleted all in-flight data in the notification pipeline in a "factory reset"
- Brought downstream systems back into a consistent state with the emptied pipeline by hand
- Action items
- Scale the existing Cassandra nodes vertically to bigger, faster servers
- Set up multiple Cassandra clusters and spread the workloads across them
- Set system load thresholds at which the Cassandra clusters are scaled out horizontally ahead of need
- Upgrade the current and new clusters to a more recent Cassandra version
- Add more load shedding techniques to control Cassandra under high load
- Bring more Cassandra expertise in-house
- Lessons
PagerDuty concluded that its Cassandra cluster was underscaled and shared by too many services with different load and usage patterns, and that the scaling work should have come before the planned Cassandra version upgrade.
- 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 cause4
Configuration change1 case
- Component
- Contributing factor
- Organisation
DNS or network fault1 case
- Component
- Contributing factor
- Organisation
Capacity exhaustion1 case
- Component
- Contributing factor
- Organisation
Operator error1 case
- Component
- Contributing factor
- Organisation