Cases6 cases

1 to 5 of 6

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-0339 Azure Front Door and Azure CDN users saw intermittent connection errors, timeouts and latency spikes for hours

   Microsoft Azure2024

   Symptoms

   From 11:45 UTC on 30 July 2024, a subset of customers got intermittent connection errors, timeouts and latency spikes when connecting to Microsoft services that use Azure Front Door (AFD) and Azure Content Delivery Network (CDN). The Azure Portal team saw the first service degradation at 11:47 UTC.

   Intermittent connection failuresIntermittent timeoutsHigh latencyPacket loss

   Trigger

   Around 11:45 UTC the Azure network DDoS protection service was disengaging after a routine DDoS mitigation and returning traffic to its default routing to AFD, but the routes at one site in Europe could not be updated because the network control plane could not reach that site during a local power outage.

   Root cause

   Configuration change

   Component

   CDN and edge networkDDoS protection serviceNetwork control plane (SDN)Data center power and cooling

   Contributing factor

   Overlapping failuresExcessive blast radiusMonitoring blind spot

   Detection

   The Azure Portal team detected service degradation at 11:47 UTC and began to investigate. At 12:10 UTC network monitoring correlated the Portal incident to a network issue at one site in Europe, and networking engineers joined.

   Remediation

   • Rerouted traffic under the standard congestion playbook, which removed most of the impact by 13:58 UTC
   • Ordered the network control plane to reissue its commands to the misbehaving device, which could not be reached
   • Removed the device that kept attracting traffic from the network and scanned the network for other issues

   Action items

   • Add the missing configuration on network devices so a DDoS mitigation issue in one geography cannot spread to another
   • Improve validation and monitoring in the Azure network to detect invalid configurations
   • Improve monitoring for when the DDoS protection service is unreachable from the control plane but still serving traffic

   View case
4. 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
5. IL-0491 Squarespace's CDN origin fleet fell below its healthy node threshold, and images, scripts and stylesheets failed to load

   Squarespace2019

   Symptoms

   At 12:10 AM ET on Tuesday, February 12, 2019, Squarespace's monitoring alerted the on-call engineer for the CDN origin fleet that the fleet had fallen below a safe number of healthy nodes. Requests to static.squarespace.com and static1.squarespace.com failed, so images, scripts and style sheets did not load for some sites, and the status page later reported elevated error rates serving media and stylesheets.

   High error rate

   Trigger

   At 10:30 PM ET on February 11, an engineer started a maintenance operation across the CDN origin fleet. The operation kept running in the background after the engineer believed it had been terminated.

   Root cause

   Operator error

   Component

   CDN and edge network

   Contributing factor

   Excessive blast radiusMonitoring blind spot

   Detection

   The monitoring system alerted the CDN origin fleet's on-call engineer at 12:10 AM ET when the fleet fell below a safe number of healthy nodes.

   Remediation

   • Restored the CDN origin fleet, partially by 2:15 AM ET and to normal behaviour at 2:20 AM ET

   Action items

   • Revise the incident-response playbooks with checks and actions for this fleet, starting with an assessment of customer impact and the immediate involvement of an Incident Commander
   • Improve external monitoring to assess customer impact of issues with the CDN partners and origin services more quickly
   • Revise operational policies and add safeguards for issuing maintenance commands, including limiting the share of the fleet a command can operate on
   • Reduce the need for direct manual maintenance operations
   • Create independent failure domains and route requests automatically around unhealthy parts of the system

   View case

By root cause5