Cases3 cases

1 to 3 of 3

1. IL-0098 After 2i2c moved from ingress-nginx to nginx-ingress, a hub's Ingress took priority over cert-manager's temporary Ingress for the same host, so new hubs could not get TLS certificates

   2i2c2026

   Symptoms

   An attempt to launch a new hub failed because its ingress could not obtain a new TLS certificate. The day before, the same engineer had recreated the support deployment on the 2i2c-aws-us cluster and seen its TLS certificate orders stuck pending.

   Misrouted requestsDeploys failing

   Trigger

   Creating new hub deployments that needed new TLS certificates on clusters recently migrated from ingress-nginx to nginx-ingress.

   Root cause

   Breaking change in an upgrade

   Component

   Ingress controllercert-manager

   Contributing factor

   Change with a delayed effect

   Detection

   An attempt to launch a new hub failed; the engineer had seen certificate orders stuck pending on another cluster the day before and declared an incident.

   Remediation

   • annotated the Ingress objects that need TLS so that cert-manager could edit them in place to complete the ACME challenge

   Action items

   • Follow-up tracked in https://github.com/2i2c-org/infrastructure/issues/8016
   • Follow-up tracked in https://github.com/2i2c-org/infrastructure/issues/3278

   Lessons

   Swapping one ingress controller for another can change how Ingress objects that share a host are combined. cert-manager's temporary challenge Ingress depends on that behaviour, so the breakage shows up when a deployment needs a new certificate. 2i2c notes that it got lucky: it had already learned of this possible cause while testing on an internal cluster, and changing the cert-manager configuration was quick.

   View case
2. IL-0022 Three overlapping infrastructure bugs (context-window misrouting, TPU output corruption and an XLA top-k miscompilation) degraded Claude's responses

   Anthropic2025

   Symptoms

   From early August 2025 a number of users reported that Claude's responses had become worse. At first the reports were hard to tell apart from the normal variation in user feedback. By late August they had become frequent and persistent enough for Anthropic to open an investigation.

   Response quality degradationMisrouted requests

   Trigger

   A bug from 5 August that sent some Sonnet 4 requests to servers configured for the upcoming 1M-token context window; a misconfiguration deployed to the Claude API TPU servers on 25 August; token-selection and sampling-code changes deployed on 25 and 26 August that removed a December 2024 workaround and exposed a latent XLA:TPU compiler bug; and a routine load-balancing change on 29 August that increased the misrouted traffic.

   Root cause

   Software defect

   Component

   Model request routingTPUXLA compiler

   Contributing factor

   Overlapping failuresMonitoring blind spotLimited debug accessIgnored early signal

   Detection

   User reports of degraded responses from early August, including reports online. They were hard to tell apart from normal feedback variation, and their rising frequency and persistence by late August led Anthropic to open an investigation; internal evaluations did not detect the degradation.

   Remediation

   • Fixed the routing logic so short- and long-context requests go to the correct server pools (deployed 4 September, rolled out to all platforms by 18 September)
   • Rolled back the TPU server change that corrupted token generation (2 September)
   • Rolled back the top-k sampling change for Haiku 3.5 (4 September), Opus 3 (12 September) and Sonnet 4
   • Switched from approximate to exact top-k and standardized some additional operations on fp32 precision

   Action items

   • Add detection tests for unexpected character outputs to the deployment process
   • Develop more sensitive evaluations that reliably tell working and broken implementations apart
   • Run quality evaluations continuously on true production systems
   • Build infrastructure and tooling to debug community-sourced feedback faster without sacrificing user privacy
   • Fix the approximate top-k compiler bug together with the XLA:TPU team

   Lessons

   Benchmarks, safety evaluations and canary deployments missed degradation that users noticed, partly because the model often recovers from isolated mistakes, and Anthropic relied too heavily on noisy evaluations, with no clear way to connect rising reports to each of its recent changes. Overlapping bugs with different symptoms on different platforms looked like random degradation, and privacy controls on user interactions kept engineers from examining the interactions needed to identify or reproduce the bugs. Anthropic concluded that it needs evaluations running continuously on production and a continuous signal from users, such as the /bug command in Claude Code and the thumbs-down button in the Claude apps.

   View case
3. IL-0186 Pods on one Kubernetes worker node could not reach external HTTP and HTTPS because storage components had added nat PREROUTING rules that redirected ports 80 and 443 to local ports

   Hans H. Kim2023

   Symptoms

   On one worker node of a Kubernetes cluster, traffic to ports 80 and 443 went missing: pods on that node could not make outbound HTTP or HTTPS requests. Infrastructure engineers and the author's teammates debugged it.

   Misrouted requests

   Trigger

   A server on which components for storage work had been installed automatically added nat REDIRECT rules for ports 80 and 443 to the node's iptables.

   Root cause

   Configuration change

   Component

   Node iptables rules

   Contributing factor

   –

   Remediation

   • had the people responsible for the storage components delete the REDIRECT rules from the node

   Lessons

   Inside Kubernetes, kube-proxy itself manages iptables rules, so the author felt that part needs to be understood in depth. When packets go missing during network tests, check each step of the path in turn, which requires knowing clearly which steps the networking goes through.

   View case

By root cause3