The forecast refreshes every hour now.

On 3 September Google DeepMind and Google Research introduced WeatherNext 3, a global weather model that produces a new forecast every hour. Temperature and moisture come out at roughly 5 kilometres, other surface fields at 10, and the atmosphere above at 25. Its predecessor worked on a 25 kilometre grid and updated every six hours. Google says it is the first global model to forecast every hour of the day, and that precipitation forecasts a day or more out are up to 50 per cent more accurate.

It already sits behind the forecasts in Search, Maps and the Gemini app. More usefully for us, it is exposed through the Maps Platform Weather API, BigQuery, Earth Engine and Cloud Storage. So this is not a research paper. It is a data source a build can call on Monday.

Six hours was a design constraint.

Most weather logic in the software we see was written around the old rhythm. Somebody checks the forecast in the morning, a decision gets made, and the rest of the day runs on it. The outdoor screen stays up or comes in. The queue plan uses the covered route or the open one. The staffing rota assumes rain or it does not. A six hour refresh made that sensible, because there was not much new information to act on before lunch.

The part of WeatherNext 3 that matters is where the speed comes from. It learns from live geostationary satellite imagery and real ground station readings rather than waiting on the traditional data cycle. Hourly runs look 48 hours ahead, and the main runs go out to 15 days as a 64 member ensemble. That is a forecast that has changed its mind, with evidence, several times before an event opens its doors.

This summer made the case without any help. The Met Office has summer 2026 provisionally as the UK's warmest on record, at a mean of 16.5°C, with 38.1°C at Kew on 13 August. Anyone who ran something outdoors in August already knows a morning forecast was not enough.

What we would build differently.

• 01Decide the thresholds before the data arrives. The wind speed at which a temporary structure is closed, the rain probability that moves the queue, agreed with the client and written into the spec. An hourly feed with no agreed trigger is just a busier dashboard.
• 02Store the forecast's issue time next to every decision the system makes. When someone asks why the screen went dark at two o'clock, the answer is a timestamp, not a shrug.
• 03Show probability, not an icon. A 64 member ensemble tells you how sure the model is. A sun with a cloud over it throws that away.
• 04Stop reacting to every run. Hourly updates will flicker around a threshold. Require the forecast to hold across two runs before anything physical changes.
• 05Keep a person and a second source in the loop. It is a vendor API with terms that can change, and 5 kilometres is still not your car park.

Should clients care.

If the thing we built for you lives indoors, no. If it lives in a car park, a fan zone, a festival site or on the side of a building, then yes, a little. Not because the forecast is better, though it appears to be. Because there is now something new to check every hour, and the systems around it were designed on the assumption that there was not.

We are not rewriting anything in a hurry. The next outdoor build gets an hourly weather input with agreed triggers and a visible audit trail, and the older ones get that conversation at their next maintenance window.