Issue affecting some parameters from the ERA5 post-processed daily statistics on single levels

An issue with the computation of some parameters from the ERA5 post-processed daily statistics on single levels from 1940 to present dataset was identified in June 2026.

The affected parameters of the ERA5 post-processed daily statistics on single levels are:

  • maximum_2m_temperature_since_previous_post_processing
  • minimum_2m_temperature_since_previous_post_processing
  • 10m_wind_gust_since_previous_post_processing
  • maximum_total_precipitation_rate_since_previous_post_processing
  • minimum_total_precipitation_rate_since_previous_post_processing

For aggregated variables, the 00:00 time step represents the aggregation period of the previous day and requires a one-hour time shift during processing. Due to an error, this correction was not applied to the affected variables listed above.
As a result, downloaded values for these variables are associated with a time period that is shifted by +1 hour relative to the timezone selected by the user.

Immediate action has been taken by the Data Stores Service team to remove access to the affected data from the dataset Download data form. While access to the affected parameters remain available through the API service, the data from the parameters listed above should not be downloaded and not used until further notice.

A fix is to be implemented as soon as possible. Please watch this Forum announcement to be notified of further updates on this topic.

For reference, this issue has been recorded as a “Known issue" in the ERA5 post-processed daily statistics documentation.

We apologise for the inconvenience this may cause and appreciate your patience and understanding.

Should you have any questions about this issue, please contact us via our Support Portal.

ECMWF Support

I access a couple of the daily mean variables from the CDS API (t2m and sst) and it have been receiving a 500 error since June 9, 00Z:

Recovering from HTTP error [500 Internal Server Error], attempt 1 of 500
Retrying in 120 seconds

As I have two different scripts for this and been doing it for quite some time I don’t think it is me (I switched to the hourly dataset temporarily until this is fixed). I think it has to do with this?

Indeed we have been getting this error 500 at least since 7am this morning but it was fine yesterday around 6pm (gmt+1), the api seems globally impacted

I have been trying to access some other variables (fal) and am getting the same issue

Hi,
please try again.

Thanks
Michela

Hello Michaela,

Do you have any estimation on when the problem is going to be solved?

Thank you;

Carlos

It seems to be working now, thanks!

Hello, Michaela.

I have tried to claim the data at 6th June 7 AM (GMT+7), but it seems that it is still showing error for me. It would sometime bug and made me to only choose 1 variable (total precipitation), even though i had clicked 7 variables before. And it seems i can only choose the frequency of 1 hour.

This part is more of a complain rather than an error report, but it seems that i can only choose 1 year, even though i needed 6 years for my research, and i think the limit of data requested can be more than 400. Icould have taken the monthly ERA5 data, but my research also took a data from a local weather station that shows daily data for 6 years, thus i cannot simply combine those two different types of data. I hope perhaps something can be done for that.

Apologies for the lenghty complains. Thank you;

Rafael

Michaela,

I just want to report that the downloads of 1 month of daily data are beeing too slow since this morning.

Yesterday a request was taking 1-2 minutes and now is taking 1:30h

Carlos

Hi Carlos,
there was a Data Stores system session earlier today which may have caused issues, see:

Can you retry your request, please?
Kevin

Thank you Kevin,
The requests are now faster (~30min), but they still take some time.

I am trying to download daily post-processed rainfall from ERA5 in a python code loop, monthly, from 2000 to 2025. Every time a request is complete, the python loop put the next request (i.e., next month of daily data).

I hope the systems at ECMWF are not making my requests longer due to the fact that i am doing request after request (in loop).

Thanks
Carlos