Anyone else noticing this? For the last three months, I've been tracking the MFA push notification success rates across our internal CI/CD and admin portals, and the data is getting concerning.
Our automated integration tests, which simulate user logins, are now flagging a **12-15% failure rate** on the first push notification attempt. The notification either never arrives on the user's device, or it's delayed by over 30 seconds. The fallback to "Enter a code" works, but it defeats the purpose of a seamless push.
Here's what I'm seeing:
* **Increased latency:** Average response time has gone from ~5 seconds to 12+ seconds.
* **Silent failures:** Sometimes the Okta Verify app shows no history of the push attempt, even though the dashboard says it was sent.
* **User frustration:** Our help desk tickets for "MFA not working" have doubled, mostly tied to push timeouts.
I've ruled out our network configs and device token issues—this feels like a service reliability problem. For a premium platform, this is a critical path that shouldn't be degrading.
Are other teams experiencing this? I'm curious if it's region-specific or more widespread. We're starting to look at alternative methods for our automated workflows because consistency is key.
Keep automating!
Interesting you're tracking this with automated tests. I've been hearing similar grumbles from our operations team, but we haven't set up formal monitoring yet.
Could you share more about how you're measuring the success rate and latency? I'm trying to build a case to start logging this in our own analytics, and seeing your method would be a huge help. Are you pulling data from Okta's system logs, or is it all from your own test suite?
If we're seeing the same trend, maybe it's time to push our account manager harder for an RCA.
Interesting that you've ruled out your network and token issues. That's the first place their support usually sends you. But have you considered your automated tests are part of the problem?
If you're hitting their endpoints with the same frequency and pattern as a real user base, I'd be surprised. Most synthetic monitoring tends to be too consistent, which can sometimes trigger different behaviors in the notification routing layer. It might not be the service degrading, but your tests hitting a newly throttled or rerouted path.
That said, if your help desk tickets have doubled, there's clearly *something* real happening. Are you seeing any correlation with specific Okta data centers or OS versions in your user complaints?
cg
Valid point about synthetic traffic patterns. It's a standard test artifact we account for by introducing jitter and randomizing device profiles. The test failures correlate directly with an uptick in our real user help desk tickets, so it's not an isolated testing anomaly.
Our user complaints aren't tied to a specific OS version. The correlation we see is with Okta's notification service status events, which have been quietly appearing more often in their health dashboard with vague descriptions like "degraded performance for a subset of users."
Have you checked if your org is pinned to a particular infrastructure region? That might explain why some are seeing this and others aren't.
SLA is not a suggestion.