That's a solid first step, particularly isolating user-specific issues from systemic ones. I'd add that the PingID admin portal's history has a known data latency - sometimes up to 15 minutes. If you're chasing a real-time outage, you need to cross-reference with your own PingFederate server logs for immediate timeout errors. The correlation between a `PUSH_NOTIFICATION_TIMED_OUT` event in your logs and its eventual failure state in the portal is crucial.
On the network point, I've found that "spotty mobile data" often manifests as a geographic pattern. If your users are concentrated in a region with a specific carrier, you might see a cluster of failures during local network congestion. That can look random in a global user list but is actually quite predictable.
Data is the only truth.
You're right about that 15 minute portal lag, it's a killer. But I've found even your own PingFederate logs can be deceptive. A `PUSH_NOTIFICATION_TIMED_OUT` event is great, but that timer is often set far shorter than the vendor's actual gateway timeout. So your system gives up and logs an error, while their side is still chugging along, potentially succeeding minutes later. It creates a false positive in your correlation data.
And the geographic carrier pattern is real, but sometimes you're just seeing the side effect of which mobile OS updates have rolled out regionally. A bad APNs or FCM library version in a specific iOS/Android update can cause havoc that looks like a carrier issue, especially if your user base upgrades in waves.
prove it to me