Incident Library
Applied filters Root causeFaulty deploymentSymptomLog floodDomainKubernetesClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases2 cases

1 to 2 of 2

  1. IL-0324 Three MediaWiki deployments lost Memcached after a PHP 8.1 rollout and overloaded the External Storage database cluster
    Wikimedia Foundation2025
    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.

    Database overloadHigh latencyHigh error rateLog floodMonitoring outage
    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
    Faulty deployment
    Component
    DatabaseIn-memory cacheConfigMaps and SecretsHelmCI system
    Contributing factor
    Unverified assumptionDependence on a warm cacheSignal buried in noise
    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.

    View case
  2. IL-0142 GKE clusters on 1.24 and later wrote unexpected fluentbit error entries such as "Failed to get record: decoder: failed to decode payload: EOF" that used up the Logging API write quota for some customers
    Google Cloud2023
    Symptoms

    From 07:13 US/Pacific on 6 July 2023, GKE customers saw unexpected additional error and warning entries in their cluster logs, written to the Cloud Logging project that holds the clusters. Standard and Autopilot clusters at GKE 1.24.x and later were affected.

    Log flood
    Trigger

    Google rolled out a new version of the GKE component that processes logs (preliminary analysis).

    Root cause
    Faulty deployment
    Component
    Telemetry agent
    Contributing factor
    –
    Remediation
    • gave customers a workaround: request a Logging API quota increase, or apply a log exclusion for the fluentbit-gke messages
    • rolled out a fix gradually to the affected clusters between 10 and 18 July 2023
    Lessons

    Log messages written by a managed logging agent count against the customer's own Logging API write quota and logging bill, so a faulty agent release can drop a customer's other logs. A log exclusion on the agent's container name and the message patterns keeps the noise out of storage until a fix arrives.

    View case
Check your cluster for this

These 2 cases involve In-memory cache and CI system. 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.

Open kubegap

By root cause1

Faulty deployment2 cases

Component
In-memory cache1CI system1ConfigMaps and Secrets1Database1Helm1Telemetry agent1
Contributing factor
Signal buried in noise1Unverified assumption1Dependence on a warm cache1
Organisation
Google Cloud1Wikimedia Foundation1
  1. IL-0324 Three MediaWiki deployments lost Memcached after a PHP 8.1 rollout and overloaded the External Storage database cluster
    Wikimedia Foundation2025
  2. IL-0142 GKE clusters on 1.24 and later wrote unexpected fluentbit error entries such as "Failed to get record: decoder: failed to decode payload: EOF" that used up the Logging API write quota for some customers
    Google Cloud2023