Every so often an airport has a day it did not plan for. A line of thunderstorms parks over a major hub nearby, and flights that were never meant to land at the smaller airport down the road start showing up anyway, one after another, because it is close, usually outside the worst of the weather, and has the runway length. The ramp fills up. Fuel, gates, ground crews, and customs all get busy at the same moment. And almost nobody saw it coming, because by the time a diverted plane touches down, the decision was made an hour earlier in the cockpit.
I wanted to know if you could see it coming. Not with an expensive platform or a data science team, but with free public data and a few evenings of work. So I picked one mid-sized airport as a test case and pulled every diverted flight that landed there over more than two years. This post is the honest version of what I found, including the part where the data told me to stop overpromising.
The question I actually wanted to answer
The goal was simple to say and hard to deliver: give airport operations advance notice that a wave of diverted flights is likely, so they can staff and prepare instead of react.
To get there I needed three things. A history of what actually happened. The weather that went with it. And a clear-eyed answer to whether the two are connected tightly enough to forecast. That last one is where most “predictive” projects quietly fall apart, so I decided up front that I would follow the numbers even if they said the idea was weaker than I hoped.
Step one: the history was free
The national transportation statistics office publishes every flight flown by reporting airlines, including a flag for whether it diverted and which airport it actually landed at. It is public, it is free, and it goes back decades. The only catch is a reporting lag of about two months, and it covers scheduled passenger carriers rather than every aircraft in the sky.
I downloaded 28 straight months, filtered for flights that diverted into my test airport, and ended up with 520 real events. Each one carried the date, the airline, where the flight came from, where it was originally headed, and when it landed. That table became the whole foundation. No subscription, no vendor, just a bit of patience with a clunky government download page.
What 520 diversions actually look like
A few patterns jumped out immediately, and they matter for anyone trying to plan around this kind of thing.
It is not a steady trickle. On 77 percent of days, the airport received zero diversions. Half of all 520 arrived on just 35 days. Four percent of the calendar carried half the load. That single fact is the entire case for an early warning system. The average day needs nothing. The exceptional day needs everything at once, and the worst day in the study brought 14 unplanned arrivals.
The season is real and repeats. Diversions climbed hard from spring into late summer and peaked in the same month both years, then fell off a cliff in early fall. The shape held across both full years in the data, which makes it usable as a planning baseline. What did not repeat was the exact count. One spring month produced 11 diversions one year and 30 the next. The calendar tells you which months to watch. It does not tell you how many.
One feeder dominated. The single busiest hub nearby sent about four of every ten diversions. Two other large airports came next. Five airports accounted for roughly three quarters of everything. That is a short enough list to actually monitor.
Adding the weather, and a clear answer on cause
Knowing when diversions happened was only half the picture. I wanted to know why. So I pulled the official recorded weather observations for each destination airport, the same reports that include a plain thunderstorm flag, real visibility, and ceiling height, and matched them to each event at the hour it happened.
The result was cleaner than I expected. Thunderstorms explained about 79 percent of the diversions. In the warm season that rose to 91 percent. Fog and low ceilings made up a small cool-season group. And about 15 percent had no significant weather at all, which are almost certainly mechanical, medical, and operational diversions that no forecast will ever catch. Knowing that roughly one in seven is unpredictable by design is itself a useful number.
The honest part: it is a risk, not a headcount
Here is where the project earned its keep, and where I had to argue with my own optimism.
I tested every day of weather at the busiest feeder hub against the days that actually sent a diversion. On days with a thunderstorm there, a diversion into my test airport happened only about a third of the time. On a random day, the baseline was 9 percent. So a storm day is roughly three and a half times more likely to produce a diversion. That is a strong, real signal.
But look at it the other way. Two out of three storm days produced no diversion at all. Whether one actually happens depends on the storm sitting over the airport during a busy arrival window, whether air traffic control issues a ground stop, and whether my test airport is the alternate the crew picks. Those are same-day, sometimes same-hour details.
That is the honest ceiling. You can tell an operations team that today carries elevated risk, and you will be right in a way that beats guessing. You cannot tell them how many planes are coming. Any tool that claims a specific flight count several days out is selling confidence it does not have.
The variable almost everyone forgets
The sharpest insight in the whole project did not come from a model. It came from a simple question: what about the receiving airport’s own weather?
The airport only works as an alternate when it is flyable itself. If the same system covers a feeder hub and the receiving airport at once, those flights go to other alternates instead, and the airport actually gets fewer diversions on what looks like a terrible weather day. So the real signal is two sided. Bad weather at the feeder airports, and good weather at home, is when you get slammed. Bad weather at both is quiet. A naive model that only watches the feeders gets this exactly backwards.
So can you predict it days ahead?
Partly, and the honest answer depends on the kind of weather. Organized systems like fronts, squall lines, and tropical storms are visible three to four days out, and those are the ones a multi-day forecast can flag. The everyday afternoon pop-up storm is not. A model can tell you the atmosphere is primed for storms, but not the timing, and timing is what decides everything.
I built a small tool that pulls the forecast for the feeder airports and for the receiving airport, then grades each of the next several days low, medium, or high, using the two-sided rule. It runs on a free weather API. It works. But testing it during a calm week taught me the last lesson: you cannot validate a forecast tool against a quiet stretch. It needs to be scored against real storm days before anyone trusts it, which is a matter of running it every morning and checking its calls against what actually happens.
What this means if you have an operations problem
I went into this wanting to build a predictor. I came out with something more useful and more honest: a graded risk signal, backed by evidence, that knows its own limits.
A few takeaways that apply well beyond one airport:
The data you need is often already public and free. Two of the best datasets in this project cost nothing.
The unglamorous finding is usually the valuable one. “It is a risk multiplier, not a count” is less exciting than “we can predict it,” and it is the version an operations team can actually act on without getting burned.
A model that reports its own accuracy earns trust. The moment a tool cries wolf without warning you it might, people stop listening. Building the honesty in from the start is what makes it usable.
You do not need a big platform to answer a real question. You need the right free sources, a clear question, and the discipline to accept the answer the numbers give you.
If you run operations for anything that weather disrupts, whether that is an airport, a delivery fleet, or a job site, the same recipe applies. Start with the history you can get for free, connect it to the conditions that drive it, and be honest about the difference between a real signal and a promise you cannot keep.
That last part is the whole game.
