Cases6 cases

3 to 6 of 6

1. IL-0290 GitLab.com's Redis Sidekiq cluster ran out of memory and lost quorum, causing 500 errors and a 12 million job backlog

   GitLab2026sev1

   Symptoms

   From 17:12 UTC on 12 May 2026, error rates rose at the same time across GitLab.com's web, Git, API and CI runner services. Users got frequent 500 errors, failed or stuck CI pipelines, authentication failures and unreliable Git access, and a Prometheus Alertmanager alert opened the incident at 17:15.

   High error rateMemory pressureThroughput degradation

   Trigger

   Earlier on 12 May, as a mitigation for a previous incident, INC-10084, a Sidekiq queueing apdex SLO violation on shard catchall-b, jobs of AuditEvents::AuditEventStreamingWorker were deferred. The deferred audit event jobs then piled up in the Redis Sidekiq cluster.

   Root cause

   Capacity exhaustion

   Component

   In-memory cache

   Contributing factor

   Change with a delayed effectPages not deliveredLimited debug access

   Detection

   A Prometheus Alertmanager alert reported the incident at 17:15:10 UTC, three minutes after impact began. A follow-up asks why the redis-sidekiq memory alert did not page, and the review says some signals did not reach the right on-call people.

   Remediation

   • Restarted and force-reset the two unresponsive Redis Sidekiq nodes
   • Stopped each Redis Sidekiq VM in turn and resized it to c2-standard-16, doubling memory and CPU
   • Re-enabled AuditEventStreamingWorker instead of deferring it

   Action items

   • Investigate why the redis-sidekiq memory alert did not page
   • Establish the root cause, failure mode and remediation status of the WebHookWorker poison pill
   • Give mitigations that disable safety limits an explicit owner and a deadline for re-evaluating them
   • Stop AuditEvents::AuditEventStreamingWorker from causing recurring incidents
   • Create a runbook for AuditEventStreamingWorker
   • Address PG connection pool saturation

   Lessons

   Broad degradation across web, Git, authentication, CI runners, Sidekiq and the internal API made it hard to settle on one cause and explain it clearly. The customer symptom of pipelines stuck in created was hard to measure in real time, and the dashboards that would have answered it were not obvious to on-call responders. Some alerts did not reach the right on-call people, and hosts that hung on login slowed diagnosis and made changes riskier. Redis-sidekiq under memory saturation forces choices between availability and data loss that are hard to make during an incident and call for guardrails and design changes.

   View case
2. IL-0435 Error rates rose as Aurora MySQL killed connections and declined queries to avoid OOM while load metrics stayed flat

   CyberAgent2026

   Symptoms

   An alert fired one day because an application's error rate had suddenly risen. The error log of the Aurora MySQL RDS instance for that time showed Aurora killing connections and declining queries to avoid running out of memory. The killed queries also made application latency worse.

   High error rateMemory pressure

   Trigger

   An application release added a batch job run every minute by a Kubernetes CronJob. Each run's short-lived pod connected to the database from a new pod IP.

   Root cause

   Capacity exhaustion

   Component

   DatabaseJobs and CronJobs

   Contributing factor

   Unreviewed defaultsChange with a delayed effect

   Detection

   An alert fired on the application's error rate.

   Remediation

   • Set performance_schema to manual management and capped two related Performance Schema parameters, unlimited by default, at 100 in the parameter group, then restarted the RDS instance

   Lessons

   When system alerts fire but the database's load metrics look calm, Performance Schema growth is worth suspecting. The two parameters that were capped are unlimited by default, so connections from ever-changing source addresses keep adding to the records. Capping them has a cost: once the cap is exceeded, per-host figures in Performance Insights are missing. Putting RDS Proxy between the application and Aurora MySQL to keep source hosts stable is another possible measure.

   View case
3. IL-0453 Hakuna API latency spiked every day during the ElastiCache Redis backup as memory filled and the backup went forkless

   Hyperconnect2022

   Symptoms

   The service API latency of Hyperconnect's Hakuna rose sharply at a certain time, periodically. The per-dependency latency analysis in the APM showed that a bottleneck in Redis caused it, but no deployment and no change in traffic pattern could have affected how Redis was used.

   High latencyMemory pressure

   Trigger

   The daily ElastiCache backup on the primary node ran while available memory was insufficient, so ElastiCache used a forkless backup that slowed user requests.

   Root cause

   Capacity exhaustion

   Component

   In-memory cacheDatabase backups and snapshots

   Contributing factor

   No alert on limit

   Detection

   A latency graph showed the service API latency spiking periodically, and the APM's per-dependency latency analysis pointed at Redis.

   Remediation

   • Moved the ElastiCache backup from the primary node to the secondary node
   • Changed the code so data stored without a TTL is stored with one
   • Replaced the Redis Hash CrudRepository usages with a CustomRepository built on RedisTemplate
   • Ran a script that deleted the unneeded data already stored, freeing 58 GB on 3 databases

   Lessons

   The team says its Redis operation and monitoring had gaps, and lists what to watch: use a relational database when data has relationships or must be searched by value; write data that must be durable to on-disk storage rather than Redis; keep available memory at 50% or more when ElastiCache snapshots must be taken; take care that O(n) commands such as DEL on a collection do not stall production Redis; and check regularly for unnecessary I/O between the application and the database. Spring Data Redis repositories, which manage secondary indexes in the framework, suit workloads that need no TTL and need fast queries.

   View case
4. IL-0382 Linode Object Storage in Newark and Atlanta returned 503 Slow Down to all clients under very high inbound traffic

   Linode2022

   Symptoms

   On 19 and 20 October 2022, Linode Object Storage in Newark and Atlanta slowed down, became less available and rate limited many requests with "503 - Slow Down" HTTP responses, after the clusters received extremely high inbound traffic in both request count and bandwidth.

   High error rateMemory pressure

   Trigger

   Extremely high inbound traffic, in both total requests and throughput, reached the Newark and Atlanta Object Storage clusters on 19 and 20 October 2022.

   Root cause

   Capacity exhaustion

   Component

   Object storage

   Contributing factor

   Unpatched known bugExcessive blast radius

   Remediation

   • Fixed the edge rate limiting so it enforces the advertised 750 requests per second per bucket
   • Adjusted Ceph tunables to stop runaway memory use during high-pressure storage events
   • Moved internal Object Storage components hit by resource contention to less busy, higher-performance infrastructure
   • Adjusted performance tunables on internal components and back-end clusters so customers were not rate limited too early

   Action items

   • Refine throughput and bandwidth throttling
   • Scale up the internal Object Storage infrastructure to spread load more efficiently
   • Look for further hardware performance improvements for the internal Object Storage infrastructure
   • Tune the load balancing algorithms to avoid hotspots in the clusters

   Lessons

   Linode's per-bucket rate limiting at the edge is meant to keep excess load off the back end; when it works as intended, the back-end limits, which throttle every client alike, should never come into play.

   View case

By root cause1