Narrative:

Planned flight. Weather for ZZZZ: ZZZZ 18/24-hour forecast 32006KT cavok (ceiling and visibility okay) PROB40 4000 br using alternate ZZZZ1 weather ZZZZ1 18/24-hour forecast VRB03KT cavok. Just after departure checked weather again. ZZZZ 18/24-hour forecast VRB03KT cavok no longer required alternate. Checked ZZZZ1 in lido and then company dashboard: valid for ETD/ETA. VRB03KT 9999 FEW002. Then noticed an alert on company dashboard and found illegal forecast for ZZZZ1 national weather service and company: taf ZZZZ1 VRB03KT 9999 SCT002 PROB40 fzfg VV001. Metar also showed ZZZZ1 600 meters and reporting RVR. Zero notification from lido for either leg because lido didn't even have correct ZZZZ taf. Deleted alternate for ZZZZ. Reworked second leg and added alternate for ZZZZ1.used to lido not alerting properly for changes of weather if station is already below what lido considers below minimums. However ZZZZ1 was cavok at planning. Flight planning support speculated that it was a time stamp issue (even though there are similar events happening that is now called overwritten/corrupt taf). Apparently there are again lido weather issues.suggest lido begin a process similar to the one for sigmets not ingested correctly no matter what the root cause. Any weather data should be handled with redundancy in the process. Also alarming is the lack of communication about these ongoing problems in lido. I double checked my email for anything about lido weather; nothing from flight planning support and nothing from flight control standards. So how is a dispatcher coming on shift supposed to even be aware that these issue exist? I already know the responses of access lido trouble tickets and other sources of weather. Not good enough. These issues should be 'pushed' out to flight control floor not something I have to hunt. Out of ordinary functions of any system used by dispatch should require notification of the floor.

Google
 

Original NASA ASRS Text

Title: A Dispatcher reported the Lido weather forecast process apparently does not update to current conditions if an airport is already below Lido minimums during the dispatch process. A destination change to below minimums was discovered on a National Weather Service forecast.

Narrative: Planned flight. Weather for ZZZZ: ZZZZ 18/24-hour Forecast 32006KT CAVOK (Ceiling and Visibility Okay) PROB40 4000 BR using alternate ZZZZ1 weather ZZZZ1 18/24-hour Forecast VRB03KT CAVOK. Just after departure checked weather again. ZZZZ 18/24-hour Forecast VRB03KT CAVOK no longer required alternate. Checked ZZZZ1 in Lido and then company dashboard: VALID FOR ETD/ETA. VRB03KT 9999 FEW002. Then noticed an alert on company dashboard and found illegal forecast for ZZZZ1 National Weather Service and company: TAF ZZZZ1 VRB03KT 9999 SCT002 PROB40 FZFG VV001. METAR also showed ZZZZ1 600 meters and reporting RVR. Zero notification from Lido for either leg because Lido didn't even have correct ZZZZ TAF. Deleted alternate for ZZZZ. Reworked second leg and added alternate for ZZZZ1.Used to Lido not alerting properly for changes of weather if station is already below what Lido considers below minimums. However ZZZZ1 was CAVOK at planning. Flight Planning Support speculated that it was a time stamp issue (Even though there are similar events happening that is now called overwritten/corrupt TAF). Apparently there are again Lido weather issues.Suggest Lido begin a process similar to the one for SIGMETS not ingested correctly no matter what the root cause. Any weather data should be handled with redundancy in the process. Also alarming is the lack of communication about these ongoing problems in Lido. I double checked my email for anything about Lido weather; nothing from Flight Planning Support and nothing from Flight Control Standards. So how is a dispatcher coming on shift supposed to even be aware that these issue exist? I already know the responses of access Lido trouble tickets and other sources of weather. Not good enough. These issues should be 'pushed' out to flight control floor not something I have to hunt. Out of ordinary functions of any system used by Dispatch should require notification of the floor.

Data retrieved from NASA's ASRS site and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.