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

Cases3 cases

1 to 3 of 3

  1. Symptoms

    From 03:45 CST on 23 April 2024, FQDNs in two system domains of Azure in China, chinacloudapp.cn and chinacloudsites.cn, gradually stopped resolving, and customers in the Azure China regions had trouble connecting to many Azure services and managing resources. Internal monitors alerted engineers to the degradation at 04:37 CST.

    Trigger

    At 03:45 CST a configuration change made through a domain registrar, as a step of a domain decommissioning workflow, updated the nameservers of chinacloudapp.cn and chinacloudsites.cn to a set of inactive servers.

    Root cause
    Component
    Contributing factor
    Detection

    Internal monitors alerted engineers to the degradation in the Azure China Cloud at 04:37 CST and created an incident, which the engineering team acknowledged at 04:39 CST.

    Remediation
    • Reverted the two domains to their previous working nameservers
    Action items
    • Suspended further runs of the domain lifecycle process until the management tool covers Azure in China
    • Make the validation process of domain lifecycle management include signals from all cloud regions
    • Add validations that get nameserver information by resolving the zone directly over the Internet
  2. Symptoms

    From 02:36 UTC on 15 May 2023, Atlassian products with services hosted in the us-west-1 region could not store or retrieve data assets such as media, attachments and build artifacts. Automated monitoring detected it within three minutes, and the status page reported intermittent errors.

    Trigger

    An internal service was migrated to a new network segment as part of an initiative to harden the partitions between network segments, and the old network stack was then removed.

    Root cause
    Component
    Contributing factor
    Detection

    Automated monitoring detected the incident within three minutes.

    Remediation
    • Rolled back the network migration change, returning Atlassian systems to a known good state
    Action items
    • Review the systems that decommission service stacks and check that customer traffic is no longer served before a stack is decommissioned
    • Add steps to the service network migration process that identify associated DNS records needing attention
    Lessons

    Atlassian said the migration used blue/green deployment to limit this kind of risk, but adequate verification was not run before the old stack was decommissioned, and moving services between network segments is rare and hard to replicate in test.

  3. Symptoms

    Between 3 and 7 June 2017, Heroku customers in both the EU and US regions had periods of high latency: some requests failed and others took an excessive time to pass through the Heroku Routing Layer. All customers in the EU and US were affected at various times.

    Root cause
    Component
    Contributing factor
    Remediation
    • Found the sources of high-volume traffic and worked with those apps' owners to distribute their requests better
    • Replaced the legacy DNS records with new, corrected DNS records
    Action items
    • Make monitoring alert engineers sooner to unevenly distributed traffic
    • Investigate how to configure DNS and load balancers to reduce the effect of high-volume and bursting traffic
    • Work with caching Add-on partners on the DNS configuration issues that affect them, to achieve proper load balancing
Check your cluster for this

These 3 cases involve Authoritative DNS servers and records and Cloud load balancer. 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