Huh that’s interesting, do you have any further context on that? I’ve not worked on a product with anywhere near that scale before so monitoring has always been whatever I can get from commercial push platforms

I mean... record the time we first send a push message, when a client connects have it tell you if it's because it got a push or user interactive start, check the time between push and connection, add that to your choice of time series graphing tool. Graph by platform, and you can see when the platforms are delaying pushes.

Some of the delay will be ordinary things like their push service fell over or is unreliable (you also get some feedback when they don't accept push messages), or their push connection runs into silent NAT timeouts on some networks. But some of it will be things like you ran into an undocumented push quota, so Blackberry users don't get timely pushes at peak, etc. On client platforms where you have reliable background execution with network connectivity, you can potentially signal connecting clients if platform push isn't working well and have them switch to persistent connections until the push service comes back. But that was never an option for iOS; it hasn't been a reasonable option for Android since at least Android 6 when Doze was introduced... and app killers before then made it hard before then; and all the other platforms are dead. Now, push really just has to work.

AFAIK, Apple has always been willing to deprioritize pushes when you send "too many", especially when there's no user interaction; or when they added silent (voip) pushes to wake up the app, they only let you have a few silent pushes if you don't post a user visible push.

For ordinary async messaging, push latency doesn't become a big deal until it hits double digit seconds. For voice/video calls, you really want pushes to be as near to real time as possible, or the caller is gone before the callee phone rings.