Is JumpCloud Down?

 ‌ ‌ **Date of Incident:** Oct 30, 2026\(UTC\) **Description**: Admin Portal and User Portal requests intermittently failed after an internal infrastructure upgrade **Region:** Mostly North America \(Eastern US\). Customers in Europe and Asia-Pacific were also affected, at lower volume ‌ **Summary:** Between 04:43 and 06:01 UTC on October 30, 2026, some JumpCloud Admin Portal and User Portal requests failed with server errors. Most of the impact was in our North America region between 05:10 and 06:01 UTC. Affected admins and users saw errors or incomplete pages when viewing devices, device command results, user portal pages and other console pages. Some admin sign-ins, Windows MDM operations and device agent requests also failed. The cause was an upgrade to an internal service that supplies feature configuration to the JumpCloud platform. That upgrade was incompatible with how one of our core application services reads that configuration. We reversed the upgrade and restarted the affected services, and service was fully restored at 06:01 UTC. **What Happened:** As part of routine security maintenance, our engineering team upgraded an internal service that tells the platform which features and settings are enabled. The new version formatted part of its configuration data differently from the previous version, sending an empty array as a null value. One of our core application services, which handles many Admin Portal and User Portal requests, couldn’t process the new format. Requests that needed that configuration failed. Errors started in Europe at 04:43 UTC and in Asia-Pacific at 04:51 UTC, both at low volume. After the North America rollout, errors there began at 05:10 UTC at much higher volume. Automated monitoring alerted our on-call team at 05:21 UTC and an incident response began. Engineers traced the errors to the upgrade and reversed it in all regions by 05:40 UTC. The affected application service had kept the incompatible configuration in memory, so reversing the upgrade did not end the errors on its own. Engineers restarted the affected services in every region. Errors stopped in Europe and Asia-Pacific by 05:54 UTC and in North America at 06:01 UTC. We confirmed with affected customers that service was restored. **Root Cause:** An upgraded version of an internal configuration service sent data in a format that one of our core application services couldn’t process. That service uses a third-party software library to read the configuration. Our version of the library has a defect in handling the new format, which the vendor has since fixed. Our other services that use this configuration were not affected. Several factors contributed to the length and scope of the incident: * **Validation:** Our checks during the rollout focused on the health of the upgraded service itself, not on error rates in the services that depend on it. * **Alert routing:** The same errors appeared in our pre-production environment several hours before the production rollout. Our monitoring detected them, but the alerts were low priority and did not reach the engineers performing the upgrade.. * **Recovery:** Because the affected service kept the incompatible configuration in memory, recovery required restarting it in every region after the upgrade was reversed ‌ **Corrective Actions:**  1. **Library update and compatibility testing**. We are updating the affected application service to a corrected version of the library. We will also test the services that depend on this configuration service against any future version before it reaches production. 2. **More resilient error handling**. We are changing the affected service to fall back to safe default settings when it can’t read configuration data, so a problem of this kind no longer causes failed requests. 3. **Deployment monitoring and alert routing**. We are building monitoring that tracks error rates across all JumpCloud services during infrastructure changes. It will bring new errors, in pre-production or production, straight to the team making the change. We are also reviewing our alerts to make sure important signals are prioritized correctly. 4. **Dependency mapping**. We are documenting which services depend on each shared infrastructure component, so the risk of an upgrade can be assessed and the right teams brought in before rollout. --- [2026-10-30T00:17:22.341-06:00] (resolved) This incident has been resolved. --- [2026-10-30T00:07:00.436-06:00] (monitoring) A fix has been implemented and we are monitoring the results. --- [2026-10-30T00:02:11.295-06:00] (investigating) We are currently investigating this issue.

 **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. --- [2026-10-23T12:25:16.342-06:00] (resolved) This incident has been resolved. --- [2026-10-23T10:24:20.015-06:00] (monitoring) 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. --- [2026-10-23T10:11:55.154-06:00] (monitoring) We are continuing to monitor for any further issues. --- [2026-10-23T10:00:11.713-06:00] (monitoring) We identified errors related to a third party service. Error rates have decreased and we are continuing to monitor. --- [2026-10-23T09:55:12.893-06:00] (investigating) We are currently investigating reports of errors when loading the JumpCloud User or Admin Portal. We will update with additional information within 30 minutes.

This incident has been resolved. --- [2026-10-22T10:50:55.594-06:00] (monitoring) A fix has been implemented and we are monitoring the results. --- [2026-10-22T10:44:05.481-06:00] (identified) The issue has been identified and a fix is being implemented. --- [2026-10-22T10:21:42.923-06:00] (investigating) We have identified an issue affecting device certificate issuance and renewal for customers in our US region, beginning at approximately 9:26 AM MT (15:26 UTC). During this time, devices requesting a new or renewed device certificate may be unable to obtain one. This primarily affects newly enrolled devices and devices whose certificates are due for renewal. Devices with existing valid certificates are not affected and continue to function normally.