Is JumpCloud down right now?

While you wait: the JumpCloud incident checklist

1. Name the dependency precisely. JumpCloud is your identity and access dependency. Identify which of these surfaces is actually in the production path: sign-in, token issuance, MFA, SSO and session renewal.
2. Confirm the affected path. Use JumpCloud's component and incident detail, then test an existing session separately from a new sign-in and verify the exact tenant, region and authentication method you use.
3. Bound every retry. Cap concurrency, use exponential backoff and retain idempotency where applicable. An upstream incident should not become a retry storm against JumpCloud or your own services.
4. Use the rehearsed fallback. For this dependency, preserve valid sessions, pause risky identity-policy changes and use a documented break-glass path only if your controls already provide one. Do not invent a new failover path during the outage.
5. Verify recovery end to end. A green JumpCloud status is the start of validation: watch for delayed webhooks, directory sync and authentication queues before declaring recovery complete.

What breaks when JumpCloud has issues

JumpCloud sits in the auth & identity layer. An incident can affect sign-in, token issuance, MFA, SSO and session renewal; the exact blast radius depends on the components, regions and features your production path uses. Treat the official component timeline as evidence, compare it with your own independent probes, and communicate the user-visible effect rather than saying the whole vendor is simply “down.”