I’m just wondering if anyone else has also noticed that downloading IFS data directly from the ECMWF Data Store has been extremely slow ever since the v50r1 upgrade occurred on the 12th of May?
I have continually being getting the HTTP 429 error “Too Many Requests” when trying to download GRIB files for the IFS model, which suggests to me that there is a higher than usual demand since the upgrade. This didn’t seem too surprising at the start. However, it’s now been a few days with no signs of improvement. I’ve tried on servers from where I work to my personal laptop, but the problem appears to be the same. So I don’t suspect the problem is localised within my own servers.
What is also concerning is that I haven’t since any discussion or reports on this from any forums or from ECMWF status pages. I’m just wondering if this appears to be a widespread issue or somehow more localised around my servers? Any feedback or information about this would be extremely helpful in helping to determine how widespread the problem is.
I’m experiencing the same problem. Since the 12th of May it’s been next to impossible to download IFS forecasts from ECMWF. As it’s been close to a week now since this problem start, I suspect that it’s here to stay for some time and that I will have to find a workaround of some sort.
Any guidance or help regarding this issue would be greatly appreciated.
I am experiencing the exact same issue. Lots of “too many requests”, failed downloads, and timeouts as a consequence. For me, the opendata server has been very unreliable, even bordering on unusable since the switch to the new model versions.
Same here. At days it is even impossible to download forecast data past forecast step 12 or 18 after trying during hours. I can’t seem to find any discussion regarding this issue.
Dear all, had the same issue reported by many users. Eventually, have managed to overcome it by using the AWS mirror, instead of downloading the data directly from ECMWF.
At the moment, we have a lot of users accessing the data and we recommend making use of all sources like AWS/Microsoft and Google if you experience slow retrievals.
Thank you Michela for your response on behalf of ECMWF Support. This provides full clarity on the situation.
Thank you to everyone else for also providing your accounts on the issue.
I have since made the switch to downloading from the AWS source (as well as using the ecmwf-opendata python package). This has brought significant improvements to downloads on my end and I am hit with rate limiting HTTP errors much less frequently from AWS.
I’ll echo Michela and ant0nis’s recommendations to divert to other sources if you are having issues downloading directly from the Data Store.
I’ll add that I’m seeing this issue as well. And AWS and Google have their own reported issues. The AWS 503 slowdown errors have been very problematic for me, to the point that I effectively can’t use AWS, and I’ve had problems with Azure that I haven’t had time to look into, so Google may be the only semi-reliable solution for me right now.
Azure usually works, but it is slow when going via the ECMWF Python interface.
A few comments:
a) Would it be possible to front the ECMWF open data store with a Content Distribution Network? I believe NCEP is using Akamai, which generally provides good to excellent performance in my experience.
b) Is it known why ECMWF downloads via AWS are so slow? It’s clearly not an inherent limitation of AWS.
c) Similar to b), Azure is also slow. This is despite the fact that I’m requesting from Azure-based servers, so I would expect good performance.
Hi,
The 503 Slow Down response is an AWS S3 throttling mechanism and it is applied dynamically based on the number of requests per second hitting a particular data path.
The ECMWF open data bucket on AWS uses date-based paths (e.g. 20260519/00z/ifs/…), which means that every user worldwide requesting the same forecast run is competing on the same path. When a large number of users and pipelines hit the same path simultaneously, AWS temporarily throttles requests with a 503 response to manage the load.
Unfortunately this is outside of ECMWF’s control, as the throttling is applied dynamically by AWS based on their own internal rate limiting logic. We do not have visibility into the exact thresholds they apply.
@Michela - I ran a quick test on two arbitrary historical dates/paths on AWS, 20250520/00z and 20240520/00z, and immediately received a 503 Slow Down response.
It’s certainly possible that those dates have many other users requesting them right now, but I think it’s safe to assume that an order of magnitude more users would be requesting the most recent dates/cycles, so it seems unlikely to be able to access recent data if something doesn’t change.
That said, I understand that this is outside ECMWF’s control, but maybe it’s worth looking into somehow.