Is JumpCloud down?

JumpCloud is currently experiencing delays in assigning Users and Systems to Dynamic Groups. Administrators may see delays in these Group membership updates, and thus delays in provisioning to connected resources.

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

We are continuing to work on a fix for this issue.

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

We are continuing to monitor for any further issues.

This incident has been resolved.

We are currently investigating delays or timeouts loading the user console. We are investigating the cause of the issues currently, and will provide an update within one hour.

We have identified that a third party outage is impacting our service. More information can be found at https://www.cloudflarestatus.com/incidents/v3yl7jqmqj51

The third party issue impacting our service has been resolved. Our internal monitoring is showing service states returned to normal.

 ‌ **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**: While this incident was caused by a third-party provider and was outside of JumpCloud's direct control, 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.