JumpCloud Status Page

Sep 25, 2026 · resolved Sep 25

This incident has been resolved.

Sep 14, 2026 · resolved Sep 14

 # **Incident Report** **Date**: Sep 21, 2026 **Date of Incident:** Sep 14, 2026 **Description**: Root Cause Analysis for RADIUS authentication failures affecting EU users **Region:** European Union \(EU\) ‌ **Summary:** On September 14, 2026, JumpCloud identified an issue affecting RADIUS authentication for users in the European Union region. Users who had recently changed their password were unable to sign in with their new password, while their previous password continued to work. The issue originated with a database replica in the EU region that stopped receiving updates from the primary database following a planned infrastructure upgrade. As a result, RADIUS authentication in the EU region was served from an out-of-date copy of directory data, and recent account changes were not reflected there. JumpCloud restored service by rerouting EU RADIUS authentication to healthy database replicas in other regions, then rebuilding and resynchronizing the affected EU replica. Authentication in the EU region was fully restored the same day. **What Happened:** As part of a planned infrastructure upgrade, the database instances supporting RADIUS authentication were upgraded in place. In the EU region, the database read replica did not resume replication after the upgrade and stopped receiving updates from the primary database beginning September 10, 2026. Equivalent replicas in other regions recovered normally; only the EU replica was affected. Because RADIUS authentication in the EU region was served from this replica, it relied on a copy of directory data that was current only up to September 10. Any account change made after that point was not reflected in the EU region until the issue was resolved. The most visible symptom was password changes -  a newly set password would fail while the previous password still worked. As a result, during the affected window, account changes made in the EU region may not have taken effect there, including changes intended to remove or suspend a user's access. Once the issue was resolved and the replica resynchronized, all pending changes were applied and EU directory data returned to a fully current state. **Contributing Factor:** The delay in detection between September 10 and September 14 occurred because the affected database instance continued to report a healthy status at the infrastructure level even though replication had stopped. Our alerting was oriented around these instance-level availability metrics and did not cover this particular replication condition, so the stopped replication did not trigger an automated alarm, masking the underlying issue. Closing this detection gap is the focus of the corrective actions below. **Corrective Actions:** JumpCloud is taking the following actions to prevent recurrence: 1. **Replication-health monitoring and alerting.** We are adding automated alerting that detects when a database replica stops replicating, independent of its general availability status, so this class of failure is caught immediately. Status: In progress. 2. **Stricter readiness validation for authentication traffic.** We are strengthening our health checks so that a replica that is not fully synchronized is automatically removed from serving authentication traffic, ensuring requests are answered only from up-to-date data. Status: Planned. 3. **Staged rollout with replication validation for infrastructure changes.** We are updating our procedures for database instance changes so they are applied one region at a time, with explicit verification that replication has fully recovered before proceeding to the next region. Status: In progress.

Sep 3, 2026 · resolved Sep 3

This incident has been resolved.

Jun 22, 2026 · resolved Jun 22

 ‌ **Date**: Jun 25, 2026 **Date of Incident:** Jun 22, 2026 **Description**: RCA for Third-Party CDN Network Disruption — Cloudflare / Zayo Fiber Cut ‌ #### **Summary:** On June 22, 2026, beginning at approximately 13:25 UTC, some JumpCloud customers experienced degraded access to web-facing services including the Admin Console, User Portal, API endpoints, and SSO authentication flows. Customers connecting through North America or accessing services routed through North American infrastructure were most affected. The root cause was a fiber cut in Eastern North America, a physical break in underground or undersea cables carrying internet traffic. Cloudflare attributed the disruption to Zayo, a network transit provider, experiencing an outage on some of its network routes, which caused reachability issues for services routing through those paths. Because JumpCloud's traffic transits the Cloudflare network before reaching JumpCloud's origin infrastructure, degradation at the Cloudflare/Zayo layer directly impacted our customers' ability to reach JumpCloud services. By late morning, most affected platforms had stabilized, with Cloudflare indicating its fix was being actively rolled out. JumpCloud's backend services and data plane remained fully operational throughout the event. The issue was isolated to the traffic path between end users and JumpCloud's origin infrastructure. ‌ #### **What Happened:** JumpCloud utilizes Cloudflare as the security and networking layer in front of all its global infrastructure. All HTTP/HTTPS requests to JumpCloud's web services traverse the Cloudflare network before reaching JumpCloud's origin infrastructure. ‌ #### **Provider Root Cause:** Cloudflare engineers first detected elevated error rates and latency at approximately 13:25 UTC on June 22, 2026. By 14:37 UTC, they had traced the root cause to a fiber cut in Eastern North America. Cloudflare confirmed that Zayo, a network provider, was experiencing an outage on some of its network routes, causing sites and services routing through those paths to become unreachable. Cloudflare's status page indicated that customers connecting through North America or accessing services in Europe may have seen increased latencies and timeouts as Cloudflare engineers worked to mitigate the issue. Traffic engineering efforts successfully mitigated the majority of congestion and packet drops, with services reported as largely stable with only minor residual impact remaining. Cloudflare's scheduled Newark \(EWR\) datacenter maintenance overlapped in timing but was a separate event - it was not the root cause of the fiber cut outage. ‌ #### **Corrective Actions \(Target End-of-July 2026\)**: While this incident was caused by a third-party provider we recognize the impact it had on our customers. JumpCloud is committed to reducing our exposure to single-provider failures and improving our resilience posture. The following corrective actions are actively underway: * **Multi-CDN Redundancy:** Cloudflare remains part of our architecture. We are adding a parallel, independently operated CDN path with weighted routing and security parity across both, so traffic can shift automatically if one path degrades. When complete, JumpCloud's edge will be capable of routing around a complete outage of any single CDN provider without customer action or service interruption. This work is in active delivery within our Platform Engineering organization. * **Resilient DNS Management:** We are modernizing how we manage DNS with phased, automated changes and rollback capabilities, reducing the risk that DNS operations themselves become a source of disruption. * **Validated Failover:** We are running controlled failover exercises including a production-scale test before relying on this redundancy in production. * **Enhanced Third-Party Monitoring & Automated Alerting:** We are expanding our monitoring to include automated detection of third-party provider degradation, enabling faster incident declaration and more rapid customer communication. This includes synthetic monitoring from multiple geographic regions that can differentiate between JumpCloud-origin issues and upstream provider issues ‌ #### **Provider Remediation:** Cloudflare has communicated the following remediation actions: * **Transit Path Restoration:** Cloudflare is coordinating with Zayo and fiber providers to repair the affected Eastern North American routes and restore full transit capacity. * **Traffic Engineering Response:** Cloudflare's traffic engineering teams implemented manual rerouting to redistribute load across unaffected network paths during the incident window. * **Ongoing Investigation:** Cloudflare has indicated a full post-incident review is underway to assess automated failover capabilities for large-scale transit provider failures. ‌ JumpCloud takes the reliability and availability of our platform seriously. We understand that our customers depend on JumpCloud for critical identity and device management operations, and any disruption, regardless of its origin, impacts their business. We are actively investing in infrastructure resilience to ensure that our dependency on any single third-party provider does not create an unacceptable risk to service availability.

May 8, 2026 · resolved May 8

This incident has been resolved.

Is JumpCloud down right now?

No — JumpCloud is up. All systems operational as of Oct 12, 4:51 AM UTC.

What is JumpCloud's current status?

JumpCloud: All Systems Operational. Alert24 checks JumpCloud's status page continuously and can notify you the moment it changes.

How do I get alerted when JumpCloud goes down?

Alert24 monitors JumpCloud and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.