Twingate Service Down

What to do

• Check whether you use Twingate Authentication - Enterprise, Identity Providers Sync, Public API, Authentication - Social and 9 more. Check your stack

  Drop a package.json, lockfile, Terraform or a list of domains at down.guide to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 39m it lasted.

  Anything that failed between 2025-05-28 20:53 UTC and 2025-05-28 21:32 UTC may need a replay.

• Subscribe to Twingate's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=twingate works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Root cause

The issue stemmed from a misconfiguration introduced during a rollout that updated routing rules in our global load balancer.

Category: BGP or network

Updates from Twingate 4

1. identifiedMay 28, 2025, 8:53 PM UTC

   The issue has been identified and a fix is being implemented.

   provider

2. monitoringMay 28, 2025, 9:16 PM UTC

   A fix has been implemented and we are monitoring the results.

   provider

3. resolvedMay 28, 2025, 9:32 PM UTC

   This incident is resolved now. We'll provide a post-mortem as soon as we have details.

   provider

4. postmortemJun 16, 2025, 6:26 PM UTC

   Incident Duration UTC Time: May 28, 2025, from 20:45 to 21:14 \(29 minutes\) Components Impacted Control Plane Services * Authentication \(Enterprise & Social\) * Multi-Factor Authentication \(MFA\) * Authorization * Connector Heartbeat Management Plane Services * Identity Provider Sync * Public API * Admin Console * Real-Time Updates * Client Log Upload * 3rd Party Integrations * Network Dashboards * DNS Filtering Dashboards Summary On May 28, 2025, Twingate experienced a service disruption that impacted multiple core services for approximately 29 minutes. The issue stemmed from a misconfiguration introduced during a rollout that updated routing rules in our global load balancer. A new routing rule was unintentionally prioritized, resulting in most API traffic being directed to a single backend. This overwhelmed the target service, leading to elevated error rates. Lower environments did not expose this issue due to their reduced traffic levels. The incident was promptly detected and the rollback was initiated quickly. However, recovery was delayed due to infrastructure dependencies that also relied on affected components. A manual intervention using local tooling ultimately restored service. Root Cause A routing misconfiguration caused a traffic imbalance that overwhelmed a backend service, leading to widespread API failures. Resolution Timeline * 20:45 UTC – Incident begins. API traffic misrouted. * 20:48 UTC – Incident detected and triage begins. * 20:52 UTC – Rollback initiated. * 21:05 UTC – Automated rollback process encounters delays. * 21:09 UTC – Engineers execute manual fix. * 21:14 UTC – Services fully recovered. Corrective and Preventative Actions Short-Term \(Completed\) * ✅ Routing rule corrected. * ✅ Alerts added to detect backend traffic anomalies in lower environments. * ✅ Improved resource scaling thresholds. Mid-Term \(In Progress\) * ⚙️ Decouple infrastructure tooling from service dependencies to ensure faster recovery options. Long-Term \(Planned\) * 🔄 Introduce backend sharding to isolate customer workloads and reduce incident impact. We sincerely apologize for the disruption and are taking actions to improve our systems' resilience. We appreciate your continued support and trust.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.