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

Cases3 cases

1 to 3 of 3

  1. Symptoms

    Railway's edge servers on Google Cloud could not route inbound requests to applications in any region for about 10 minutes, on 17 December 2024 UTC. Private networking, outbound requests, Metal Hosts and Dedicated Instances kept working.

    Trigger

    A merged Terraform change emptied the array of a static IP block list, to unblock a customer whose IP had been blocked since before Railway moved to a dynamic block list and who had reported intermittent timeouts.

    Root cause
    Component
    Contributing factor
    Detection

    Automated alerting paged the current on-call engineer at 12:49 am UTC, two minutes after the change was merged.

    Remediation
    • Reverted the change to the IP allow-list rules
    • Applied the reverted change through the Terraform runner
    Action items
    • Automatically apply a page override for merged changes, for faster notification
    • Skip the Terraform plan phase during a revert
    • Remove the offending firewall rule safely
    • Audit all remaining legacy Google Cloud firewall rules for loose specificity
    • Move to its own metal infrastructure while keeping GCP and adding AWS, for resilience and fault isolation
  2. Symptoms

    At 01:40 UTC on 14 February 2023, Twingate saw the number of connections drop in two of its Relay clusters, the one in us-east4 (Ashburn, Virginia) and the one in europe-west6 (Zurich, Switzerland).

    Trigger

    At 01:00 UTC on 14 February, Twingate started a Terraform change to all of its Relay clusters worldwide to add spot instance scaling; the rollout took about 45 minutes.

    Root cause
    Component
    Contributing factor
    Detection

    At 01:40 UTC Twingate noticed a decrease in the number of connections in the two clusters and started investigating.

    Remediation
    • Disabled the pods in the two affected Relay clusters at 02:04 UTC so Clients and Connectors reconnected to the next closest Relay cluster
    • Corrected the Terraform configuration error and redeployed the affected clusters at 03:30 UTC
    Action items
    • Make the staging environment reflect the sizing and configuration differences between Relay clusters
    • Create Terraform plans automatically for every environment and configuration variation on feature development branches
    • Extend Relay health checks so a cluster is not discoverable to Connectors and Clients when its network firewall tag is missing
    • Research and introduce staggered Terraform rollouts for the Relay cluster infrastructure
    • Add multi-cluster connectivity to Connectors so they handle regional Relay cluster problems automatically
  3. Symptoms

    From 9:28am Pacific Time on 8 March 2016, applications on the cloud.gov PaaS that relied on outbound traffic to reach the services they depended on became unavailable, and at one point every application on cloud.gov was down.

    Trigger

    At 9:28am Pacific Time on 8 March 2016 a contractor at Aquilent changed the AWS security group settings, one of several changes made in the process of achieving ATO for the platform.

    Root cause
    Component
    Contributing factor
    –
    Remediation
    • Added exceptions for individual applications, which restored some of them
    • Rolled back the security group change, which restored all applications
    Action items
    • Put all security group configuration into version control and make changes through pull requests
    • Monitor the applications running on cloud.gov and alert the cloud.gov team when they do not work as expected
    • Use CF security groups instead of AWS security groups and make the current rules visible to the cloud.gov team and the teams using it
    • Create a notification system to reach the key contact of each application on the platform
    • Create a more accurate staging environment to test changes like this
Check your cluster for this

These 3 cases involve VPC route tables and firewall rules and Terraform. 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 cause1