Flight delay data explained. How flight delay is measured (scheduled vs estimated vs actual time), what on-time performance means, how airport and airline delay data is structured, delay categories, and how to access live flight delay data through a flight data API.
A flight delay sounds simple — the plane left late. But in aviation data, a delay is a precise, calculated value, and understanding how it is calculated is the difference between a useful dataset and a misleading one.
At its core, a delay is the gap between when a flight was supposed to operate and when it actually operated. Every scheduled flight carries a planned departure time and a planned arrival time. As the day unfolds, those planned times are updated with estimates, and finally replaced with actual times once the aircraft pushes back from the gate and touches down at its destination. The delay is the arithmetic difference between the planned time and the estimated or actual time, expressed in minutes.
This matters because there is no single "delay" for a flight — there are two. A flight can leave its origin late but make up time in the air and land on schedule, or it can leave on time and still arrive late because of holding patterns, taxi queues or a gate that is not free. For that reason, serious flight delay data distinguishes departure delay from arrival delay, and treats them as separate numbers.
For developers, analysts and product teams working with aviation data, the flight delay is one of the most requested data points there is — it drives passenger notifications, compensation claims, airport transfer logistics, insurance products and airline performance benchmarking. This guide explains how delay data is structured, how it is measured, what "on-time performance" means, and how to access live flight delay data through the AirLabs platform.
"A delay is not an opinion — it is the difference between two timestamps. Everything useful you can do with flight delay data depends on knowing which two timestamps you are comparing and which time zone they are in."
Every delay calculation rests on three layers of time data. Getting these straight is the single most important concept in working with flight delay data.
The scheduled time is the time published in the airline's timetable, sometimes months in advance. It is the baseline against which all delays are measured. If a flight is scheduled to depart at 19:53, that figure never changes — it is the reference point.
The estimated time is the airline's or airport's best current prediction of when the flight will actually operate. It updates continuously as conditions change: a fresh weather forecast, a late inbound aircraft, a crew that is still completing a previous leg. When a departure board flips from "On Time" to "Delayed — now 22:10," it is the estimated time that has changed.
The actual time is recorded once the event has happened — the moment the aircraft pushes back from the gate (actual departure) or touches down and reaches the stand (actual arrival). Until that moment, the actual time does not exist; the best you have is an estimate.
The delay, then, is computed as:
departure delay = estimated (or actual) departure − scheduled departure
arrival delay = estimated (or actual) arrival − scheduled arrivalA flight with a scheduled departure of 19:53 and an estimated departure of 22:10 is carrying a departure delay of 137 minutes. Once it actually pushes back, the actual time replaces the estimate and the delay figure is finalized.
A critical practical detail: these timestamps can be expressed in local airport time or in UTC. Comparing a local departure time at one airport with a local arrival time at another — across time zones — without converting to UTC first is one of the most common sources of wrong delay calculations. Robust delay data always carries a UTC version of each timestamp alongside the local one.
Because departure and arrival delays are distinct, they tell different operational stories, and choosing the wrong one for your use case produces misleading results.
| Delay type | What it measures | Best used for |
| Departure delay | Lateness leaving the origin gate | Gate operations, boarding logistics, turnaround analysis |
| Arrival delay | Lateness reaching the destination stand | Passenger compensation, connection risk, transfer scheduling |
Consider an airport transfer or ground-transport service. What it cares about is arrival delay — when the passenger will actually be at the destination, ready to be collected. A flight that departed two hours late but recovered the time in the air arrives on schedule, and the driver should not be sent late.
Now consider a flight delay compensation or insurance product. Most regulatory frameworks — such as the EU's air passenger rights rules — base eligibility on arrival delay at the final destination, not departure delay. A claims engine that keys off departure delay would approve and reject the wrong claims.
By contrast, an airline operations dashboard tracking gate efficiency cares primarily about departure delay, because that is the part of the process the ground team controls.
The lesson is that "is this flight delayed?" is an incomplete question. The useful question is "is the departure delayed, the arrival delayed, or both — and by how many minutes?"
On-time performance is the headline metric the entire industry uses to summarize delay data, and it is more nuanced than it first appears.
On-time performance is the percentage of flights that operate within an agreed tolerance of their scheduled time. The near-universal industry convention is the "A14" or 15-minute rule: a flight is counted as "on time" if it arrives (or departs, depending on the metric) within 14 minutes and 59 seconds of schedule — in practice, anything under 15 minutes late is "on time." A flight 15 minutes late or more is counted as delayed.
This threshold has important consequences for anyone interpreting OTP figures:
For product builders, the practical takeaway is that on-time performance is a derived statistic — it is computed by applying the 15-minute threshold to underlying per-flight delay values. If you have access to the raw delay minutes for each flight, you can compute OTP for any airline, route, airport or time window yourself, and you can even change the threshold to suit your own definition of "on time."
Delays and cancellations are closely related but are not the same thing, and any complete delay dataset has to handle both.
A delay means the flight still operates, just late. A cancellation means the flight does not operate at all. In the data, this distinction is carried by the flight status field, which typically takes values such as scheduled, active, landed and cancelled. A cancelled flight has no actual departure or arrival time because those events never occur — so any delay calculation must check status first and skip the arithmetic for cancelled flights, rather than producing a nonsensical "delay" from a missing timestamp.
For passenger-facing products, the distinction is everything: a delayed passenger waits, while a cancelled passenger needs rebooking. For analytics, cancellations and delays should be reported as two separate rates, because an airline can keep its delay figures low precisely by cancelling its most troubled flights — so reading delay data without cancellation data gives an incomplete picture of reliability.
Behind every delayed flight is a cause, and the industry classifies these causes into broad categories. Understanding them helps when interpreting patterns in delay data, even when a specific feed does not attach a reason code to each individual flight.
| Category | Typical causes |
| Air carrier / airline | Crew availability, maintenance, baggage loading, aircraft cleaning |
| Weather | Storms, fog, snow, high winds at origin, en-route or destination |
| Air traffic / ATC | Airspace congestion, ground stops, flow control, runway capacity |
| Late-arriving aircraft | The inbound aircraft for this flight was itself delayed (knock-on delay) |
| Security | Screening backlogs, terminal evacuations, security incidents |
The single most important category to understand is late-arriving aircraft, because it is the mechanism by which one delay early in the day cascades into many delays later. Aircraft fly multiple legs per day; if the first flight is two hours late, every subsequent flight on that airframe inherits a head start on being late. This is why delays cluster in the afternoon and evening, and why analyzing delay data over a full day reveals propagation patterns that a single-flight snapshot cannot.
Weather is the largest single external cause, but it is worth noting that weather delays at one airport ripple outward through the late-arriving-aircraft mechanism to airports that have perfectly clear skies. This interconnection is why airport delay data is most meaningful when viewed across a network rather than airport by airport.
Delay data is most often sliced two ways — by airport and by airline — and each lens answers different questions.
Airport delay data aggregates delays by location: which airports are experiencing the most departure or arrival delays right now, or on average. This is the view that matters for ground operations, airport transfer services, and anyone whose logistics depend on a specific location. A surge of delays at a single hub — caused by weather or a runway closure — is immediately visible in airport-level data and lets operations teams react before the knock-on effects spread.
Airline delay data aggregates delays by carrier: which airlines are running late, and by how much, across their whole network. This is the view used for competitive benchmarking, service-level monitoring and passenger-facing reliability scores. Because a single airline operates across many airports, airline delay data smooths out the location-specific spikes that dominate airport data and instead reflects the carrier's overall operational discipline.
The richest analysis combines the two: the same delay event can be filtered to show "delays at this airport, for this airline" — for instance, to understand whether a hub problem is hitting all carriers equally or concentrated in one. Both views are simply different aggregations of the same underlying per-flight delay records, which is why having access to the raw flight-level delay data is what makes both possible.
There are two fundamentally different temporal modes of delay data, and they serve different products.
Live (real-time) delay data answers "what is delayed right now?" It reflects the current state of departure and arrival queues, updating as estimates change through the day. This is what powers passenger notifications, real-time airport boards, transfer dispatching and live compensation triggers. It is inherently forward-and-present looking: it tells you about flights happening now or in the next few hours.
Historical delay data answers "how late has this route, airline or airport been over time?" It is the basis for on-time performance scores, reliability benchmarking, route-planning analytics and academic research into network behavior. Historical data is about accumulated patterns rather than the present moment.
Most products need one or the other clearly. A flight-status app or a transfer service is built on live data. A reliability-ranking site or an airline-benchmarking dashboard is built on historical aggregates. Knowing which mode your use case needs — before you start building — saves a great deal of rework.
AirLabs provides live flight delay data through a dedicated Flight Delay API, designed to surface delayed flights across every airport in the world in a single call, with filtering by airport, airline or specific flight.
The endpoint is built around a minimum-delay threshold: you specify how many minutes of delay you care about, and whether you want departures or arrivals, and it returns the matching flights.
json
GET https://airlabs.co/api/v9/delays?delay=60&type=departures&api_key={KEY}
[{
"airline_iata": "BA",
"flight_iata": "BA6984",
"dep_iata": "MIA",
"dep_time": "2021-07-14 19:53",
"dep_estimated": "2021-07-14 22:10",
"arr_iata": "SFO",
"arr_time": "2021-07-14 22:52",
"arr_estimated": "2021-07-15 01:09",
"status": "scheduled",
"duration": 359,
"delayed": 137
}]In this single record, the delayed field gives the delay in minutes, while the dep_time / dep_estimated and arr_time / arr_estimated pairs expose the scheduled-versus-estimated timestamps the delay is derived from — so an application can show not just "delayed 137 minutes" but the specific new departure time. Each timestamp is also available in UTC for safe cross-time-zone comparison.
For airport transfer services, insurance products and flight delay compensation engines — the use cases this endpoint was designed for — the ability to ask "show me every arrival running more than 60 minutes late at this airport" in one request is exactly the primitive those products are built on.
For applications that need the full per-flight picture rather than only the flights currently exceeding a delay threshold, the Flight Schedules API returns the complete schedule for an airport or airline with the same timing fields, plus explicit dep_delayed and arr_delayed values that separate departure delay from arrival delay.
GET https://airlabs.co/api/v9/schedules?dep_iata=MIA&api_key={KEY}
[{
"flight_iata": "BA6984",
"dep_iata": "MIA",
"arr_iata": "SFO",
"dep_time": "2021-07-14 19:53",
"dep_estimated": "2021-07-14 22:10",
"dep_actual": "2021-07-14 22:10",
"arr_estimated": "2021-07-15 01:09",
"status": "scheduled",
"dep_delayed": 137,
"arr_delayed": 137
}]The separate dep_delayed and arr_delayed fields mean your application does not have to compute the difference itself — but because the raw scheduled, estimated and actual timestamps are all present, you can recompute, re-threshold or aggregate them however your product requires, including deriving your own on-time performance percentages across any airline, route or time window you choose.
A handful of patterns recur in almost every production system that handles flight delay data.
A cancelled flight has no actual departure or arrival, so subtracting timestamps produces garbage. Branch on the status field first: compute delay only for flights that are operating, and route cancelled flights into separate handling.
Local airport times are convenient to display but dangerous to compute with, because origin and destination can sit in different time zones. Do all delay arithmetic on the UTC versions of the timestamps, then convert back to local time only for display.
Decide up front whether your use case is about leaving late or arriving late. Transfers and compensation almost always want arrival delay; gate and turnaround operations want departure delay. Mixing them silently is a common and costly bug.
Rather than depending on a pre-computed OTP number whose threshold and time window you cannot see, compute OTP yourself from raw per-flight delay minutes. That way you control the threshold (15 minutes, or your own) and the scope (this route, this week, this airline).
When studying delay patterns over a day, remember that late-arriving aircraft propagate delays forward. A late-afternoon spike often originates in a single morning disruption — so analyzing a full operating day reveals causes that a single snapshot hides.
Report the two metrics independently. An airline can suppress its average delay by cancelling its worst flights, so reading delay figures without cancellation figures overstates reliability.
If you are building a flight-status app, an airport transfer service, a delay-compensation or travel-insurance product, or an airline-reliability analytics platform, flight delay data is the core signal your product runs on — and the way you measure, filter and interpret it determines whether the product is trustworthy.
The AirLabs Developer API gives you the building blocks to work with delay data directly:
dep_delayed and arr_delayed fields and full scheduled / estimated / actual timestamps.status field (scheduled, active, landed, cancelled) to distinguish delays from cancellations._fields to return only the data your application needs.You can try it right now without any obligation. Get a free flight API plan and see for yourself that we have exactly the delay data you need.
If you need more information, don't hesitate to contact us. We are always happy to help you find the right approach for your delay-data use case.
Explore AirLabs, or create an account instantly and start using API.
Get FREE API Key