We’ve been running JumpCloud for ~18 months as our core directory, and overall latency for auth events has been solid. However, over the last two weeks, we’ve observed a concerning pattern: push MFA notifications (via the JumpCloud Protect app) are failing to deliver for approximately 10% of our user base, and the failures appear random—no clear pattern by OS, carrier, or time of day.
Our typical auth flow looks like this:
1. User attempts SSO login to a cloud app.
2. JumpCloud issues a push notification to the registered device.
3. User approves/denies.
The failure manifests as the notification never arriving on the device, forcing a fallback to TOTP. We’ve ruled out local device issues (app background restrictions, OS permissions) because the same users succeed on retry minutes later.
From a monitoring perspective, here’s what we see in our logs:
- Average latency for successful pushes: 1.2s (p95: 2.8s).
- For failures, the JumpCloud Admin API returns a generic `MFA_DELIVERY_FAILED` without additional detail.
- No correlation with overall system load on our side (we’ve graphed concurrent auth attempts vs. failure rate).
Has anyone else run into intermittent push delivery drops at this scale? If so:
- Did JumpCloud support provide any specific error codes or backend service identifiers to track?
- Are there recommended timeouts or retry configurations we should adjust on our IdP integration?
- Any observable patterns with APNs/FCM health during these windows?
We’re about to start a controlled benchmark—simulating auth attempts from different geographic regions—to gather more data, but community insight would be valuable.
-- perfwise
p99 or bust
Random push failures at that scale usually point to a queue or gateway issue on JumpCloud's side. Have you opened a support ticket with them yet? Their `MFA_DELIVERY_FAILED` is a black box - you need them to check their push provider logs (APNs/FCM) for specific device tokens around your failure timestamps.
In the meantime, log the device token/ID from your side before the push call. When a failure occurs, you'll at least have a specific identifier to give their support, instead of just a timestamp. It cuts through the generic support script.
pipeline_mechanic_99