Twingate Status Page

May 28, 2026 · resolved May 28

We are currently awaiting the completion of our cloud provider’s investigation into the issue. In the meantime, we continue to closely monitor the system, and all service metrics have returned to normal operating levels. At this time, we are closing this incident. We will publish a comprehensive incident report as soon as it becomes available.

May 8, 2026 · resolved May 8

**Components impacted** * Data Plane - Relay 443 flows only **Summary** On May 9, 2026, a subset of Twingate customers experienced an interruption to network access affecting Relay 443 connectivity. The disruption lasted approximately 2 hours and 10 minutes and was caused by a configuration error introduced during a routine software update. We have resolved the issue and are taking concrete steps to prevent a recurrence. **Root Cause** Twingate regularly releases software updates to our relay infrastructure, deploying them in stages across groups to minimize risk. As part of this update cycle, we also migrated our deployment tooling to a newer version of our infrastructure management system. The newer tooling applies stricter configuration validation rules than its predecessor. While preparing the update, our team identified and corrected a configuration conflict this stricter validation had surfaced. However, the fix was shipped in the same release bundle as a second change that was designed to serve as a prerequisite — specifically, a change that prevents the stricter validation from modifying existing, live deployments. The result was that a critical network configuration — the definition that tells our relay nodes to accept connections on port 443 — was silently removed from existing cluster deployments. **Why wasn't the issue detected earlier with the initial rollout?** Our continuous smoke testing did not include end-to-end coverage for Relay 443 specifically, so no automated alert fired when previous groups were deployed. Because those early upgrade groups carried relatively low Relay 443 traffic, no customer-visible impact surfaced either, leaving the issue undetected for approximately 48 hours until the higher-traffic groups were rolled out. **Why wasn't the issue caught in lower environments?** The issue was identified in a lower environment and a fix was prepared. However, the fix was deployed in the same release as the problematic change rather than as a prerequisite, which prevented it from taking full effect on existing cluster upgrades. Subsequent deployments confirmed the issue was fully resolved. **Remediation** Once we confirmed the root cause, we re-deployed the corrected relay configuration — explicitly restoring the port 443 host mapping — across all cluster groups in sequence. We validated each group before proceeding to the next. Full recovery was confirmed at 11:55 UTC on May 9. **Corrective actions** Short-term: * **Completed:** Redeployed to production to confirm the fix is stable and the issue will not recur. * We are adding regional smoke tests for Relay 443 to match the coverage already in place for other relay deployments, ensuring failures like this are caught before impacting customers.

Oct 20, 2025 · resolved Oct 20

This incident has been resolved.

Jun 12, 2025 · resolved Jun 12

Our cloud provider has confirmed full recovery of their services, and our backlog of Events has now been fully processed. We consider this incident fully resolved.

May 28, 2025 · resolved May 28

### **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.