Flight delay prediction datasets on Kaggle: the 2015 USDOT benchmark and what surrounds it

Datadory scores it 9 out of 10, tied for the highest mark in the six-primary passenger airlines slice. Provenance is why it became the standard delay-prediction benchmark: the rows originate from BTS Form 234 on-time reporting, which is U.S.-government work free of copyright.

Provenance is why it became the standard delay-prediction benchmark. The rows originate from BTS Form 234 on-time reporting, which is U.S.-government work free of copyright, and the Kaggle mirror ships under commercial delivery terms - a combination that lets papers, courses and products share identical rows and identical results. The snapshot is static, published February 2017 and never revised, which is precisely what reproducible model comparisons want and what anyone forecasting current operations must route around.

See the 2015 Flight Delays and Cancellations (5.8M U.S. Flights) record page for field-level notes and scoring detail, or the ml-ready flight delay snapshot definition for what makes a delay table trainable in the first place.

Each of the 5,819,079 rows carries airline, flight number, origin and destination airport, scheduled and actual times, delay minutes, and cancellation and diversion flags. Two lookup files complete the bundle: airlines.csv holds all 14 reporting carriers in just 359 bytes, and airports.csv lists 322 airports with coordinates in roughly 24 KB, so you can geocode origin-destination pairs without sourcing a second file.

Scale is manageable but real. Uncompressed, flights.csv alone runs about 586 MB - big enough that column typing deserves deliberate choices, small enough that no cluster is required. Everything arrives as zipped CSV, meaning no API client, key or rate limit sits between you and the rows.

One structural fact matters for feature engineering: geography beyond the 322 listed airports cannot be recovered from the bundle itself, which is where the OpenFlights reference layer below earns its place.

The archive supports a full classifier or regressor build without leaving the folder:

Worked to this recipe, the set behaves like the benchmark it is: identical bytes across teams, a single unambiguous grain of one row per flight segment, and enough volume - 5,819,079 rows - that even rare events such as cancellations yield thousands of positives.

The practical division of labour: use the Kaggle set when you need a fixed, citable benchmark, and use TranStats when you need years the mirror does not cover, the newest closed months, or custom extracts - the vs BTS TranStats comparison works through the choice record by record.

Delay behaviour is network-shaped, so the strongest builds join reference and context layers around the label table. Five cataloged sources cover the span:

For a non-U.S. angle, EUROCONTROL publishes daily dashboards plus bulk XLSX/CSV/Parquet series with en-route delays starting January 2011, and its ADRR holds more than 25 million flights of trajectory data - the closest open counterpart for European schedule reliability work.

Two caveats shape prototyping. The test environment is explicitly limited to development purposes and serves a subset of real data: its Airline Routes snapshot is static as of November 2021, and On Demand Flight Status returns a snapshot rather than a live feed. Validate latency and coverage assumptions against production quotas before wiring a deployed model to it - the Amadeus for Developers record keeps the terms detail.

For record-level detail and adjacent questions: the ml-ready flight delay snapshot glossary entry defines what makes a per-flight table trainable, and the airline on-time performance entry covers the official BTS record type behind both sources. The vs BTS TranStats comparison works through the benchmark-versus-archive choice record by record.