Thanks for getting back to me. Yes, I do not expect anyone here to understand the specifics of the networking library we are using in our back end rust service, and it isn't necessary. The two important parts to note are: This is only a very small percentage (well under 1%) of our requests failing due to connections closure. Within a set of requests (with the same payload to different devices) we will see only a portion of them hit connection resets. If we were incorrectly formatting tokens in the requests, I would expect all them to consistently fail or succeed. In these cases our connection is aburbtly closed while requests are in flight. We do not receive an HTTP status code here to parse, as the connection was broken before it completed normally. This issue involves the communication from our back end servers to APNs and not APNs to Apple devices in question, so I don't think I can get you any relevant sysdiagnose logs. APNs not provide an idempotency key to include in our request, so we must understand the exact semantics of when resending requests are safe, otherwise we will send duplicates notifications. The two things we are trying to learn are: Is this low rate of connection resets expected, or is it due to some issue with our requests that we can fix? Is it safe to retry here without concern of double sending push notifications? Neither are discussed in the public documentation for connecting to APNs.