This incident has been resolved.

Between approximately 15:20 and 15:50 UTC on October 23, 2026, some customers were unable to reliably load the JumpCloud Admin Portal and User Portal. Affected users may have seen error pages or slow, incomplete page loads. The cause was a network disruption at one of our third-party content delivery and security providers, which affected traffic through some of their Eastern US locations. Once their network stabilized, access to both portals returned to normal, and we have confirmed that the issue has been fully resolved. We know how much you depend on reliable access to JumpCloud to manage your organization, and we’re sorry for the disruption this caused you and your users. Even when a disruption starts with a provider, keeping you connected is our responsibility. We already have redundancy in place for this kind of event, and we are actively strengthening it so that failover happens faster and more automatically in the future. We are conducting a full review of this incident and will publish a Post-Incident Review here with a detailed timeline, root cause, and the steps we’re taking to prevent a recurrence.

We are continuing to monitor for any further issues.

We identified errors related to a third party service. Error rates have decreased and we are continuing to monitor.

We are currently investigating reports of errors when loading the JumpCloud User or Admin Portal. We will update with additional information within 30 minutes.

 **Date of Incident:** Oct 23, 2026 **Description**: Admin Portal and User Portal intermittently unavailable due to a third-party network disruption **Region:** North America \(Eastern US\). Some users outside the US whose traffic was routed through the affected Eastern US network locations were also impacted. ‌ **Summary:** Between approximately 15:21 and 15:46 UTC on October 23, 2026, some customers could not reliably load the JumpCloud Admin Portal and User Portal. Affected users saw error pages or slow, incomplete page loads. The cause was a network disruption at one of our third-party content delivery and security providers. A connectivity failure in their Eastern US network caused congestion and packet loss. Access to both portals returned to normal once the provider’s network stabilized. ‌ **What Happened:** At about 15:21 UTC, error rates for portal requests passing through our content delivery provider rose sharply. They peaked at about 15:38 UTC, then dropped back to normal levels between 15:44 and 15:46 UTC. During this window, requests routed through the provider’s affected Eastern US locations failed or timed out, while requests routed through other locations were largely unaffected. Our team was alerted by customer reports and opened an incident response at about 15:47 UTC. The provider’s network had already begun to recover by then. Because the disruption was limited to a single region, it did not meet our criteria for failing over to our secondary content delivery path. We confirmed that errors had returned to baseline and confirmed with affected customers that access was restored. We then posted a status page update identifying the third-party cause. ‌ **Root Cause:** A connectivity outage at an upstream network provider used by our content delivery and security provider caused congestion and packet loss between two of their Eastern US data centers. Portal traffic routed through those locations could not reliably reach JumpCloud. JumpCloud keeps a secondary content delivery path for broad outages that affect multiple regions or services. Failover moves all portal traffic for every customer at once, so it carries its own risk of disruption. We reserve it for events where the impact is wide enough to justify that risk. This event was a single-region disruption that affected a portion of customers for about 25 minutes. Failing over would have put the larger, unaffected population at risk, so failover was not appropriate. A contributing factor was that our monitoring did not alert on the elevated edge error rates, so we detected the issue from customer reports rather than automated alerting.  That factor has already been addressed. ‌ **Corrective Actions:** 1. **Automated failover for broad provider outages.** We are completing work to make failover between content delivery providers automatic for multi-region and multi-service outages, so we can respond to large-scale events faster and more consistently. 2. **Proactive alerting on edge errors.** We are adding automated alerts on elevated error rates from our content delivery layer, including regional spikes, so our team can respond to provider issues before customers report them. 3. **Third-party status integration.** We will integrate our critical providers’ status feeds into our incident tooling to shorten the time between a provider-side event and our response. 4. **Clear failover decision criteria.** We are documenting the criteria for when to fail over, weighing the scope of a provider disruption against the risk failover poses to customers who are not affected. This will make sure every incident is assessed the same way.