Flight Performance Data — How to Measure On-Time Performance via API

Flight performance data explained. How to measure on-time performance (OTP), calculate delay metrics, benchmark airlines and airports on punctuality, and build performance monitoring pipelines using the AirLabs API — with scheduled versus estimated time differentials.

Sergey St.

Published on Jul 20th 26

Share:

• 
• 
• 

The OTP Metric — Aviation's Universal Performance Language

On-time performance, universally abbreviated as OTP, is the single most reported operational metric in commercial aviation. Every major carrier publishes it in quarterly investor decks. Every civil aviation authority tracks it. Every industry ranking of airlines and airports uses it as the primary punctuality measure. The industry-standard variants — OTP15 (percentage of flights operating within 15 minutes of scheduled) and OTP60 (within 60 minutes) — are the vocabulary aviation professionals use when they talk about operational reliability.

Behind OTP is a simple data structure: for every flight, three timestamps matter — the scheduled time, the estimated time, and the actual time. Their differences produce every performance metric that matters. Delay in minutes is actual − scheduled. Punctuality bands, cancellation rates, arrival reliability, hub bank recovery — all of them derive from that same triple. A performance data pipeline is, at its core, a system for capturing, aggregating and analysing that three-timestamp differential across many flights.

This guide covers what flight performance data actually is, how to acquire it through the AirLabs API, and the analytical patterns that turn raw timestamp differentials into published OTP metrics and internal performance dashboards. It complements our Real-Time Flight Tracking for Business guide, which covers the operational side — who tracks flights and why. This guide covers the analytical side — how to measure and report on the resulting data.

"Every flight is a data point in three dimensions: when it was supposed to happen, when it looked like it would happen, and when it actually happened. Every performance metric in commercial aviation is a function of those three numbers. Get that triple right and everything else follows."

Scheduled, Estimated, Actual — The Three Timestamps

Understanding the three-timestamp model is the first step in any performance data work.

Scheduled — the time the airline published in the schedule. This is the reference point — the commitment to passengers, the anchor for delay calculations, the baseline for OTP measurement. The dep_time and arr_time fields in the AirLabs Flight Info API and Schedules API return this scheduled time in local airport time.

Estimated — the current best forecast for when the flight will operate. This updates in real time as conditions change. If the aircraft is at the gate on time, estimated equals scheduled. If a two-hour delay is announced, estimated shifts forward two hours. The dep_estimated and arr_estimated fields carry this real-time forecast.

Actual — the observed time the flight actually operated. Departure actual is the moment wheels-up (or, in some data sources, off-block). Arrival actual is touchdown (or on-block). Once a flight has landed, actual becomes the definitive number for performance analysis.

For a flight that has already landed, the delayed, dep_delayed and arr_delayed fields in the AirLabs Flight Info API return the resulting delay directly in minutes:

GET https://airlabs.co/api/v9/flight?flight_iata=BA117&api_key={KEY}

{
  "flight_iata": "BA117",
  "dep_iata": "LHR",
  "arr_iata": "JFK",
  "dep_time": "2026-07-21 10:00",
  "dep_estimated": "2026-07-21 10:47",
  "arr_time": "2026-07-21 13:15",
  "arr_estimated": "2026-07-21 14:02",
  "status": "active",
  "delayed": 47,
  "dep_delayed": 47,
  "arr_delayed": 47
}

In this example the flight is running 47 minutes late — a straight dep_estimated − dep_time calculation, exposed as an integer in the response. Every OTP measurement in production analytics reduces to this single differential aggregated across many flights.

Querying Performance Data at Airport and Route Level

Individual flight lookups are the atomic unit, but performance analysis works at the aggregate level — how does JFK perform on Monday mornings, how does Ryanair's summer OTP compare to Lufthansa's, how does the LHR–JFK route pattern shift across weekdays.

The Schedules API returns the schedule and status for every current flight at an airport, making it the natural feed for airport-level performance analysis:

GET https://airlabs.co/api/v9/schedules?dep_iata=JFK&api_key={KEY}

The response contains scheduled and estimated times for every departing flight, allowing per-airport OTP aggregation in one call. To narrow to a specific carrier or route, add airline_iata=BA or arr_iata=LHR.

For dedicated delay-focused acquisition, the Flight Delay API returns only flights currently running delayed, filtered by airport and delay direction:

GET https://airlabs.co/api/v9/delays?dep_iata=JFK&type=departures&api_key={KEY}

This is the highest-signal endpoint for performance work — every response record represents a departure or arrival that has already breached its scheduled time. Aggregating the results shows the current disruption picture at any airport, weighted by delay magnitude rather than count.

Performance Analytics Patterns

Once performance data is flowing through the pipeline, several analytical patterns produce the metrics operational teams actually use.

OTP by carrier. Aggregate the delayed field across all flights for an airline over a rolling window. Count departures with delayed ≤ 15 as on-time (OTP15); count delayed ≤ 60 as OTP60. Divide by total departures to produce the percentage. Repeat by day, week, month for trend series.

OTP by route. Same calculation, filtered by dep_iata and arr_iata. Route-level OTP reveals whether specific city pairs run reliably or chronically late. Long-haul routes typically show higher variance than short-haul. Business-heavy morning departures show different patterns than leisure evening flights.

OTP by hour of day. Group flights by the hour of dep_time. Early-morning departures typically show the industry's best on-time performance — the first bank of the day operates from clean aircraft with rested crews. Later banks degrade because of accumulated delays from earlier waves. This diurnal pattern is a defining characteristic of hub operations.

OTP by day of week. Aggregate by day of week of the scheduled departure. Monday and Friday business routes may show worse on-time performance than midweek because of higher demand and more constrained aircraft utilisation. Weekend leisure routes may show weather-driven volatility.

Delay magnitude distribution. Beyond on/off-time binary counts, the distribution of delay minutes matters. An airline with average delay of 45 minutes but median of 5 minutes has very different operational characteristics from one with average and median both at 25. Histogramming delayed across many flights reveals whether delays are concentrated in tail events or spread evenly.

Airport punctuality benchmarking. Compare aggregate OTP across airports. Hub airports typically show worse performance than point-to-point airports because their operations are more interdependent. Airports serving multiple hubs (LHR, FRA, ORD) tend to underperform against airports with simpler traffic profiles.

Route-level cancellation rate. The status: cancelled field is a separate performance signal from delays. Cancellation rate — cancelled ÷ scheduled — is often reported alongside OTP and can move in opposite directions (an airline may improve OTP by cancelling marginal flights instead of running them late).

Historical Performance Analysis and the Alert API

Performance analysis often requires observing flights across their full lifecycle rather than snapshots. The Flight Alert API is the acquisition mechanism for this — a webhook-based subscription that pushes notifications when any tracked field on a flight changes.

The pattern for a performance data pipeline is:

• Subscribe to flights of interest via the Alert API — by airport, airline, route or specific flight identifier
• Receive webhooks when scheduled, estimated, gate, terminal or status fields change
• Store each notification with its timestamp in your database
• Reconstruct the flight's history from the sequence of updates — when the delay was first announced, when the gate changed, when the estimated shifted

This produces a much richer dataset than periodic polling. A polled snapshot shows the state at that moment; a webhook log shows the sequence of state changes — when knowledge of a delay first entered the system, how it evolved, when it stabilised. For statistical analysis of delay announcement lead times, propagation of delays through hub banks, or operational responsiveness to disruption, the alert-driven acquisition pattern is the appropriate architecture.

Building a Performance Monitoring Pipeline

A production flight performance data pipeline typically has four layers:

Acquisition. Feed structured performance records into your database from AirLabs endpoints. For airport-wide monitoring, poll the Schedules API at appropriate intervals (30–120 seconds) or subscribe via the Flight Alert API. For per-flight tracking with high granularity, use Alert webhooks keyed to the specific flights of interest. For live position validation of active flights, cross-check with the Real-Time Flights API.

Storage. Persist each record with the timestamp of observation. Include flight_iata, dep_iata, arr_iata, dep_time, dep_estimated, arr_time, arr_estimated, status, delayed, dep_delayed, arr_delayed. For alert-driven acquisition, store the sequence of updates rather than the latest state only.

Aggregation. Compute the derived performance metrics — OTP15, OTP60, average delay, cancellation rate — across the dimensions that matter for your reporting (carrier, airport, route, time bucket). These aggregations power dashboards and reports rather than being computed on demand from raw data.

Presentation. Deliver the metrics through the appropriate interface — real-time dashboards for operations analysts, weekly PDF reports for management, API endpoints for downstream consumers, alerts on threshold breaches for exception monitoring.

For applications that need to combine airport-level performance with airline-level performance and route-level analysis, joining performance data with the Airlines Database (carrier context) and Airports Database (airport context) at the aggregation layer produces the multi-dimensional views most performance analytics requires.

Who Uses Flight Performance Data

Flight performance data is consumed by a specific set of analytical teams — separate from the operational users who use live tracking day-to-day.

Airline internal analytics teams monitor their own OTP against target thresholds, benchmark against competitors and identify recurring performance issues. Performance data feeds daily operations meetings, weekly performance reviews and quarterly board reporting.

Consultancies preparing airline benchmarking studies, market entry assessments and airport performance evaluations use structured performance data as primary input. Historical OTP trends inform operational recommendations and competitive positioning analysis.

Compensation platforms and travel insurance providers rely on validated delay data to assess claims eligibility and to construct actuarial models of expected disruption. The delayed field values across many observations are the raw input to actuarial pricing.

University research groups studying air transport reliability, network resilience, delay propagation and operational efficiency use structured performance data as a primary research input. The three-timestamp differential model supports rigorous statistical analysis of operational patterns.

Trade media and specialist publications increasingly produce data-driven coverage of airline and airport performance — annual OTP rankings, seasonal punctuality reports, disruption analyses. Programmatic access to performance data enables the systematic reporting that manual data collection cannot support.

Airports use their own performance data alongside competitor and comparable-airport performance to plan capacity investment, negotiate slot allocation and support commercial positioning. Comparative benchmarking across airports informs strategic decisions.

Practical Patterns for Performance Data Work

Several patterns appear repeatedly in production performance analytics:

• Always cache the reference data. Airport codes, timezones, airline names, aircraft models change rarely. Cache from the Airports Database, Airlines Database and Fleets Database at ingestion time rather than joining live.
• Use field selection for large aggregations. For OTP computation you need flight_iata, dep_iata, arr_iata, dep_time, dep_estimated, status and delayed. Requesting only these via _fields keeps responses compact.
• Store both scheduled and estimated at every observation. Some analyses need to know what the estimated time was at earlier moments — for delay announcement analysis or disruption propagation studies.
• Handle timezones carefully. Scheduled and estimated times are returned in local airport time. For cross-airport analysis, convert to UTC using the timezone field from the Airports Database.
• Distinguish delay from cancellation. OTP and cancellation rate move independently. Some carriers manage OTP by cancelling marginal flights; analysing both jointly is essential to interpret performance accurately.
• Separate outlier events from typical operations. Weather closures and industrial actions produce large delay spikes that are not representative of typical operational performance. Publish both raw and outlier-adjusted OTP series if the audience expects operational-quality benchmarks.
• Cross-validate with live tracking. For high-stakes performance claims (published rankings, regulatory submissions), cross-reference schedule-derived actual times with live position data from the Real-Time Flights API.

Flight Performance Data for Analysts

If you are building airline benchmarking reports, airport performance dashboards, actuarial delay models, aviation research pipelines or any application whose primary output is an operational reliability metric, the AirLabs API provides the scheduled-estimated-actual timestamp triple across every flight it tracks — plus the reference data needed to join, filter and aggregate at the dimensions your analysis requires.

Supported API Features

Our Developer API allows you to create a custom experience for your users and increase the value of your product:

• Flight Information API returning scheduled, estimated and delay fields per flight (dep_time, dep_estimated, arr_time, arr_estimated, delayed, dep_delayed, arr_delayed, status).
• Schedules API returning the same performance fields for every current flight at any airport.
• Flight Delay API returning only flights currently running late, filtered by airport and direction.
• Flight Alert API for webhook-based acquisition on every field change — the foundation of longitudinal performance history.
• Real-Time Flights API for live position validation of scheduled arrivals.
• Airlines Database with carrier context for joining performance data at the airline level.
• Airports Database with timezone, geolocation and connections for cross-airport analysis.
• Aircraft Fleets Database for adding aircraft type and age context to performance records.
• Field selection via _fields for lean, targeted responses.
• JSON, XML and CSV response formats behind a single API key.

You can try it right now without any obligation! Get a free flight API plan and see for yourself that we have exactly the data you need!

If you need more information, don't hesitate to contact us. We are always happy to chat with our customers and are sure to find a customized solution for each request.