Intermittent issues accessing the JumpCloud Admin portal

What to do

• Check whether you use JumpCloud Admin Console - US Region in 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 31m it lasted.

  Anything that failed between 2025-11-19 06:46 UTC and 2025-11-19 07:16 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. investigatingNov 19, 2025, 6:46 AM UTC

   We're currently investigating reports of intermittent access issues with JumpCloud's Console Service for administrator at https://console.jumpcloud.com/. We are investigating the cause of the issues currently, and will update the status event once resolved.

   provider

2. monitoringNov 19, 2025, 7:00 AM UTC

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

   provider

3. resolvedNov 19, 2025, 7:16 AM UTC

   Issue is resolved and closed.

   provider

4. postmortemNov 21, 2025, 6:25 PM UTC

    ‌ **Date**: Nov 21, 2025 **Date of Incident:** Nov 19, 2025 **Description**: RCA for Admin Portal Login Errors ‌ **Summary:** On November 19, 2025, starting at approximately 04:30 UTC, between 1-5% of requests experienced intermittent failures to successfully authenticate to the Admin Console, lasting until roughly 06:30 UTC.  Users attempting to authenticate received an “unexpected” error message during this window, but subsequent retries may have been successful. **Root Cause:** This issue was triggered during a standard infrastructure update and traffic shift intended to move services to a new, updated cluster.  The core issue was a combination of an infrastructure configuration mismatch and gaps in our detection and validation processes. 1. Configuration Drift: The new infrastructure cluster \(Green Cluster\), intended to host the service, was missing a single but essential configuration value used by the control plane’s service mesh. This value had been recently applied to the existing cluster \(old cluster\) but was inadvertently excluded when the new cluster's baseline configuration was created and branched.  When production traffic began routing to the new cluster, the missing configuration caused some access components to fail, leading to the login errors. 2. Detection Gaps: The application logged the configuration failure as a _Warning_ message, rather than a critical error. This meant our automated monitoring system did not trigger an immediate alert or rollback when the issue first occurred. The team quickly isolated the issue to the new Green Cluster, and an emergency process was initiated to immediately revert all production traffic back to the stable old cluster. ‌ **Corrective Actions / Risk Mitigation:** 1. Automated Configuration Diff Check - Implementing an automated process to continuously compare and ensure 100% configuration parity between old and new production clusters during all transition phases. 2. Clear Rule Enforcement - Reinforcing and automating the process to ensure all configuration changes are applied consistently across all active and future clusters. 3. Multi-Layer Error Monitoring - Implementing error rate monitoring at every layer of the network and application stack to ensure no failure goes undetected.

   provider

Corrections

None so far.

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