Over the last couple of weeks we have been experiencing intermittent time outs when making requests to various eRS FHIR API endpoints. We are using CIS 2 and unattended access. Most of them have been when requesting an attachment download. A request, > 3 hours later, to download the same attachment will be successful. The latest failure details are as follows:
2026-06-23 14:16:30.004 +01:00 [DBG] A042:Retrieve Attachment ‘Digital weight management NEL CEG (R.rtf’ for UBRN 000481******. xCorrelationId:f821b7df-bff1-446b-b4e1-ae9fe31f1d8b.2026-06-23 14:16:30.006 +01:00 [INF] Sending HTTP request GET https://api.service.nhs.uk/referrals/FHIR/R4/Binary/44f8c698-35c6-4f06-b49c-*2026-06-23 14:18:10.030 +01:00 [ERR] The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
We don’t log the 307 response or the Location header so we can’t tell if its the 307 that’s causing the timeout.
Are you able to investigate the request with the xCorrelationId shown above? We are trying to find out if its an issue at the eRS end or our own.
Hey Neil,
Thanks for your query. I am looking into this now.
Hi @Neil_Davies,
We’ve investigated the request with correlation ID f821b7df-bff1-446b-b4e1-ae9fe31f1d8b and can confirm this is an eRS-side issue. The request reached our API gateway but our backend did not respond within the timeout window, resulting in a 504 Gateway Timeout. The 307 redirect was never generated, so the issue is not related to the redirect or S3 download stage.
Looking at your traffic over the last 30 days, 22 out of 57,566 requests were affected (0.038%), so the impact is very small. However, we understand this is still disruptive when it does occur.
We are investigating why these intermittent timeouts are happening on our side. In the meantime, we would recommend implementing a retry with backoff for any requests that receive a timeout or 504 response, as these failures are transient and a subsequent request typically succeeds.
We’ll update you if we identify a root cause or make any changes.
Thanks,
George
Hi @George_Craft,
Thank you for the update. We do have a backoff and retry policy and send a total of 3 retries after 2, 6, and 14 seconds after the initial request, but i’ve just realised although it handles 504’s is doesn’t handle timeouts correctly. We’ll look into getting this fixed, and hopefully that will resolve the issue our side.