Incident Library
Applied filters ComponentCDN and edge networkSymptomService outageFactorMonitoring blind spotClear 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

Cases4 cases

1 to 4 of 4

  1. IL-0512 xpro.mit.edu returned 503 for an hour when its Kubernetes/APISIX origin certificate expired after renewal failed
    MIT Open Learning2026sev1
    Symptoms

    At 3:38 PM EDT on 3 June 2026, alerts fired because both the xPRO production CMS and the main xPRO site at https://xpro.mit.edu were returning 503 errors. Fastly, in front of the site, could not connect to the Kubernetes/APISIX origin, because the origin certificate for xpro-web.odl.mit.edu had expired at 3:29 PM EDT.

    Service outageTLS certificate errors
    Trigger

    The origin certificate xpro-cert for xpro-web.odl.mit.edu, issued on 2026-03-05 with a 90-day validity period, expired at 3:29 PM EDT on 3 June 2026.

    Root cause
    Configuration change
    Component
    cert-managerCDN and edge networkAuthoritative DNS servers and records
    Contributing factor
    No configuration testsMonitoring blind spotChange with a delayed effect
    Detection

    Alerts for the xPRO production CMS and the main xPRO site fired at 3:38 PM EDT on the 503 errors, and a Rootly incident was created at 4:08 PM EDT.

    Remediation
    • Deleted and recreated the stale cert-manager certificate resources so that cert-manager issued a fresh origin certificate
    Action items
    • Remove the backend origin domain from the non-OpenEdX xPRO Fastly TLS subscription, so Fastly manages only xpro.mit.edu
    • Deploy the Pulumi update for the xPRO application in Production
    • Trigger cert-manager renewal of the xPRO certificate after the conflicting Fastly validation CNAME is removed
    • Consider tests or policy checks that keep cert-manager-managed origin domains out of Fastly TLS subscriptions
    • Consider alerting earlier on failed cert-manager CertificateRequests and Orders, so stale ACME failures are found before the certificate expires
    Lessons

    Reading the outage as a failed cert-manager ACME renewal was true but incomplete; the missing part was that Fastly had been set to manage validation for a backend origin domain that belonged to cert-manager. The team concluded that TLS certificates and DNS validation records need guardrails around ownership, and that public Fastly frontend domains and Kubernetes/APISIX origin domains must not be treated as interchangeable service domains in TLS automation.

    View case
  2. IL-0257 canva.com went down for about 50 minutes when 1.5 million requests per second OOM-killed every API Gateway task
    Canva2024
    Symptoms

    On 12 November 2024, after a new version of Canva's editor was deployed at 8:47 AM UTC, the editor's object panel stayed in a perpetual loading state for many users, particularly in Asia. Then from 9:08 AM UTC to about 10:00 AM UTC canva.com was unavailable and all requests to it failed.

    Service outageOOMKilledHigh latencyPacket loss
    Trigger

    At 8:47 AM UTC a new version of the Canva editor page was deployed, and client devices began fetching its new static assets through Cloudflare while the network path between Cloudflare's Singapore and Ashburn locations was losing packets.

    Root cause
    Dependency failure
    Component
    CDN and edge networkAPI gatewayAmazon ECS
    Contributing factor
    Overlapping failuresMonitoring blind spotRetry stormAutomation amplificationUnpatched known bug
    Remediation
    • Added a temporary Cloudflare firewall rule at 9:29 AM UTC that blocked all traffic at the CDN so new API Gateway tasks could start
    • Redirected canva.com to the status page
    • Restored traffic gradually, starting with Australian users under strict rate limits
    Action items
    • Write a runbook for rerouting, blocking and progressively restoring traffic
    • Show users a more informative error page when canva.com is unavailable
    • Raise the baseline number of API Gateway tasks and the memory of each task
    • Add load shedding rules to the API Gateway for similar traffic patterns
    • Load test the API Gateway regularly
    • Deploy the patch for the thread-locking bug in the telemetry library
    • Add multithreaded tests for the contended code path to the telemetry library microbenchmark suite
    • Use page load completion events as a second canary indicator for page asset releases
    • Experiment with adding another rollout stage to the canary to give more time to detect issues
    • Add timeouts so user requests do not wait excessively long for assets
    • Work with Cloudflare to understand the system interactions behind the incident
    View case
  3. IL-0522 An ingress-nginx chart upgrade deleted the jenkins.io Ingress and Fastly served HTTP/503 errors for hours
    Jenkins project2021
    Symptoms

    At 11:32 UTC on 18 November 2021, a user reported in the jenkinsci/jenkins Gitter channel that https://www.jenkins.io/doc/pipeline/steps/ was answering HTTP/503 errors with the message "Guru meditation" from Fastly's varnish.

    Service outageResources deleted
    Trigger

    The ingress-nginx Helm chart was upgraded from 4.0.6 to 4.0.8 at 10:42 UTC, and the new chart added an admission webhook rule that forbids Nginx configuration blocks in Ingress annotations.

    Root cause
    Breaking change in an upgrade
    Component
    Ingress controllerAdmission webhookHelmCDN and edge network
    Contributing factor
    Unverified assumptionCache-masked failureMonitoring blind spotHarmful manual action
    Detection

    A user reported in the jenkinsci/jenkins Gitter channel at 11:32 UTC that a jenkins.io page answered HTTP/503 errors, and status.jenkins.io reported the incident at 11:49 UTC.

    Remediation
    • Disabled the automated systems, rolled the ingress-nginx chart back to 4.0.6 and deleted the admission webhook by hand
    • Removed the forbidden annotations from the jenkins.io configuration
    • Upgraded the jenkins.io Helm chart to the last version known to work with ingress-nginx 4.0.8
    • Redeployed the jenkins.io Helm chart through the automated system and told Fastly to drop all cached pages
    Action items
    • Always read the changelog in depth when updating the ingress controllers, with two people pairing in real time
    • Add custom Datadog monitoring for www.origin.jenkins.io so that such an outage is detected
    • Make the monitor send the Host header www.jenkins.io so it is not redirected to Fastly
    • Check a set of pages, such as the pipeline steps page, not only the front page
    • Consider an ephemeral k3s end-to-end test before deploying to production
    Lessons

    Trusting a patch version of a Helm chart for the Ingress controller without reading its changelog in depth let a new admission rule remove the jenkins.io Ingress in production. Without monitoring on origin.jenkins.io, a user found the outage. A complete staging cluster with the same DNS setup would have caught the problem before production.

    View case
  4. IL-0388 A Google Cloud live migration took a Discord Redis primary offline, and the failover broke API instances and then guilds
    Discord2017
    Symptoms

    At about 14:01 PDT on 13 October 2017, Discord engineers were alerted to anomalies by real-time metrics and monitoring. A Redis instance that was the primary of a highly available cluster used by the API services had dropped offline after Google Cloud Platform migrated it automatically, and some API instances did not handle the failover to the secondary node correctly.

    Failover failureHigh latencyService outage
    Trigger

    Google Cloud Platform automatically migrated the Redis instance that was the primary of a highly available cluster used by the API services, and the node incorrectly dropped offline.

    Root cause
    Software defect
    Component
    In-memory cacheDatabaseCDN and edge network
    Contributing factor
    Unpatched known bugOverlapping failuresMonitoring blind spot
    Detection

    Real-time metrics and monitoring alerted engineers at 14:01 PDT. The second phase was seen at 15:41 as another anomaly in monitoring, and end user reports of servers appearing offline were escalated at 15:42.

    Remediation
    • Ran a rolling restart of all API instances to clear the Redis connection issues
    • Corrected the misconfigured edge caching rule for the expensive API route
    • Disabled the problem API endpoint on the edge network
    • Recovered the Cassandra cluster
    • Ran a second rolling restart of all API instances for the latency left by the Cassandra issues
    • Removed the misbehaving guilds node from the service hashring
    • Forcefully restarted the misbehaving guilds node
    • Restarted the whole service, forcing all users to reconnect
    • Blocked traffic that relied on the failing push component to reduce its load
    • Corrected the API setting that lets users reconnect quickly and safely
    Action items
    • Fix the known issues with Redis failover within the coming weeks
    • Change the cached route so this type of error does not degrade other services
    • Monitor the signals that would have warned of the cascading failure
    • Improve the reliability and failure handling of the affected services
    • Roll out an update of the library with the suspected flaws
    View case
Check your cluster for this

These 4 cases involve CDN and edge network and Admission webhook. 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 cause4

Configuration change1 case

Component
CDN and edge networkcert-managerAuthoritative DNS servers and records
Contributing factor
Change with a delayed effectMonitoring blind spotNo configuration tests
Organisation
MIT Open Learning
  1. IL-0512 xpro.mit.edu returned 503 for an hour when its Kubernetes/APISIX origin certificate expired after renewal failed
    MIT Open Learning2026

Dependency failure1 case

Component
API gatewayCDN and edge networkAmazon ECS
Contributing factor
Automation amplificationUnpatched known bugMonitoring blind spotOverlapping failuresRetry storm
Organisation
Canva
  1. IL-0257 canva.com went down for about 50 minutes when 1.5 million requests per second OOM-killed every API Gateway task
    Canva2024

Breaking change in an upgrade1 case

Component
Admission webhookCDN and edge networkHelmIngress controller
Contributing factor
Unverified assumptionCache-masked failureHarmful manual actionMonitoring blind spot
Organisation
Jenkins project
  1. IL-0522 An ingress-nginx chart upgrade deleted the jenkins.io Ingress and Fastly served HTTP/503 errors for hours
    Jenkins project2021

Software defect1 case

Component
In-memory cacheCDN and edge networkDatabase
Contributing factor
Unpatched known bugMonitoring blind spotOverlapping failures
Organisation
Discord
  1. IL-0388 A Google Cloud live migration took a Discord Redis primary offline, and the failover broke API instances and then guilds
    Discord2017