Minor incident

JumpCloud: Degraded User and Admin portal

Affected: Admin Console - US Region, User Console - US Region, Admin Console - EU Region, User Console - EU Region, Admin Console - IN Region, User Console - IN Region

Current status of JumpCloud: Operational — live JumpCloud status

Timeline

1. Oct 30, 2026, 06:02 UTC
   investigating
   We are currently investigating this issue.
2. Oct 30, 2026, 06:07 UTC
   monitoring
   A fix has been implemented and we are monitoring the results.
3. Oct 30, 2026, 06:17 UTC
   resolved
   This incident has been resolved.
4. Nov 3, 2026, 23:38 UTC
   postmortem
    ‌ ‌ **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 moni

Updates as published by JumpCloud (original).