Degraded User and Admin portal

What to do

• Check whether you use JumpCloud Admin Console - US Region, User Console - US Region, Admin Console - EU Region, User Console - EU Region and 2 more in apac, eu, us. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 15m it lasted.

  Anything that failed between 2026-10-30 06:02 UTC and 2026-10-30 06:17 UTC may need a replay.

• Subscribe to JumpCloud's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=jumpcloud works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from JumpCloud 4

1. investigatingOct 30, 2026, 6:02 AM UTC

   We are currently investigating this issue.

   provider

2. monitoringOct 30, 2026, 6:07 AM UTC

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

   provider

3. resolvedOct 30, 2026, 6:17 AM UTC

   This incident has been resolved.

   provider

4. postmortemNov 3, 2026, 11:38 PM UTC

    ‌ ‌ **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.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.