Hey Kevin, Thanks for the response. Originally, the timeoutIntervalForResource was set to 60 seconds, and the timeoutIntervalForRequest was default. We were still getting these errors in the wild. The only reason I implemented these times is because I implemented a retry once this specific error came in, and the server has a 15 second timeout. I am not opposed to increasing those times at all, but I am not sure this solves the root issue. But yes, this data is pretty ephemeral, so "if you can't get me this data in the next don't bother trying at all" is exactly what we were going for. We also have an app refresh we call that uses this same code that is called regularly throughout the day. That will also exhibit this error on occasion. "If you're launching immediately after restart, then you can easily be in a situation where our radios have not fully initialized and/or the backend support daemon hasn't fully launched. Those delays could easily add 5-15s of delay in starting your transfer, at which point we'll end the entire request based on timeoutIntervalForResource." That is a worry of ours. These were the steps where we could reproduce the error, but they are not the conditions that we would expect with the errors in the wild. And, because this is in the background, getting a Sysdiagnose Log is a non starter, because the user won't know it failed to initiate one. With regard to the foreground fetches, they are not being done with this code. They are performed with an asynchronous data fetch. The only reason I included that was simply to show that the endpoint was up and radios working before the background fetch was made, to try to eliminate that as a possible issue. The "backend support daemon hasn't fully launched" is a concern, and it may be the cause of this relocation of the problem, but not for what we see in the wild. The issue occurs when the app has been in the background and/or has been stopped by the system. But only occasionally. The issue we have is being able to get logs and traces on it as a result. Could there be an issue we are triggering with the backend support daemon that we are inadvertently triggering? If so, how best to avoid it This is a question that I really can't seem to find an answer on. This part of the system is triggered by a silent APNs. It is my understanding that we get 30 seconds total processing, give or take, ymmmv, to complete the processing. It is also my understanding that this time is suspended once the fetch request(s) are sent, until the delegate is called. Is this correct? Also, am I correct in my guess that the Network Trace showing "No connection" literally means a connection wasn't attempted by the OS? We are showing no connection errors from the server, but it also has to get through Cloudflare. Any assistance is greatly appreciated. This is a very difficult issue to debug, and we have been dealing with it for at least 9 months that we know of. I would really like to put this to bed.

To add a few more details here: I don't believe I mentioned this is being called in the background. The basic code I am using is: let configuration = URLSessionConfiguration.background(withIdentifier: sessionIdentifier) configuration.timeoutIntervalForRequest = 15 // The backend times out in 15 seconds configuration.timeoutIntervalForResource = 15 configuration.isDiscretionary = false let session = URLSession( configuration: configuration, delegate: self, delegateQueue: nil ) let task = session.downloadTask(with: request) task.resume() In the delegate, I am implementing both urlSession(_:downloadTask:didFinishDownloadingTo:) and urlSession(_:task:didCompleteWithError:) Using the same server endpoint, I am successfully completing the fetch when the app starts up, albeit using data(for:delegate:). The issue does not just occur after restart. It will also randomly occur, but I can replicate it reliably after restart.