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

Cases2 cases

1 to 2 of 2

  1. 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.

    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
    Component
    Contributing factor
    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
  2. 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.

    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
    Component
    Contributing factor
    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
Check your cluster for this

These 2 cases involve CDN and edge network and API gateway. 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.

By root cause2