You can use flight status codes together with reported times to enable a more complete understanding of the data we provide.
Cirium is the largest aggregator of flight status information. We consume hundreds of data feeds from airlines, airports, government agencies, and third-party data providers to provide the most accurate status information on commercial flights.
Our processing algorithms interpret information and record the most up-to-date information about the status of any flight. This information is recorded in a simple data structure that applications can consume to present the data.
Our data structure consists of:
Status codes and current gate and runway times
Departure and arrival gate and terminals
Baggage claim information
We report the most accurate information based on everything known about the flight, but we also depend on data feeds that might be conflicting, incomplete, or incorrect.
An airline publishes the schedule internally and to us. We’ll then distribute it to other airlines, airports, government systems, third-party developers, and others through data drops and our Flight Schedule APIs.
Airlines also distribute their schedules to booking agents who sell tickets for flights. Depending on the carrier, the schedule can be published 300 days or more before the flight departs. Airlines update and remove flight schedules, but these become less frequent as the departure date approaches.
We start tracking flight status approximately three days before scheduled departure. Most changes to flights begin about 24 hours before departure. Airlines file flight plans with air traffic control systems, which include the estimated departure and arrival times. Airlines update departure and arrival gate information as soon as they know what gates their flight will use. They also update aircraft information if the type of aircraft has changed from what was originally scheduled.
We’ve described the typical scenario for aviation operations. However, the aviation business is often unpredictable, and flights sometimes encounter the following issues:
They can be delayed or canceled before departure
They might return to the airport after departure
They might arrive at a different airport than originally scheduled
Disruptive events such as storms, airport strikes, etc. might change arrival times
Flight data information can vary greatly by airline for the following reasons:
Some airlines might not update data feeds
Some updates aren’t made in a timely manner
People enter incorrect information
Data providers can suffer system failures, impacting the quality of the data we receive
Every flight in our system is assigned a status code that describes the current state of the flight. This table provides a quick explanation of the codes. They are described in greater detail later in the document.
A flight that we have a schedule or flight plan for that hasn’t departed or has been canceled.
A flight that either left the gate or the runway and is on its way to its destination.
Landed or Arrived
A flight that landed on the runway or arrived at the gate at the destination.
A flight that one or more data sources have indicated is canceled.
The flight is being redirected to another airport.
A flight that has landed or arrived at the gate of an airport where it wasn’t scheduled to arrive.
We were unable to detect the final arrival status.
The flight was scheduled by mistake.
Here are more details about the flight status codes listed above.
Most flight status records in the Cirium Flight Status system are created three days before the scheduled departure. This prevents the schedule change churn that happens as airlines update schedules during the previous 300 days or more. This status is based on the schedules published by an airline.
We create the flight status record with a status code of S. The published gates times and scheduled gate times are based on the schedule. Other information updated at this time (if provided by the airline) is:
Gate and terminal information
Upline and downline information
Flight type and traffic restrictions
Scheduled block and taxi times
Our data collection process can create a flight status record at a later point if we get information from one of our data sources and the flight doesn’t already exist in our system. In this case, the record is created with the current status of the flight that the data source is indicating. It could be Scheduled, or Active, or in a final state such as Landed or Canceled. As the flight isn’t created from a schedule, some of the other information listed above isn’t filled in.
Estimated departure and arrival times are typically updated while a flight is in the S state. Departure gate and terminal information might be updated as well.
Our collection process updates status codes based on what our data sources are reporting. In some cases, we may ignore status updates if we have conflicting information or the data source is unreliable.
When we detect that a flight has departed, the status code changes to A, which means Active. This happens when:
A flight has left a gate, and the ActualGateDepartureDate is set
A flight has left the runway, and the ActualRunwayDepartureDate is set
We get a status update from a source that indicates it is active, even if no dates were updated
The typical state transition is from Scheduled to Active. However, it’s possible to transition to other states as well. It’s also possible that we didn’t receive the departure information, but instead got the information upon arrival. In this case the flight doesn’t enter the A state.
Equipment and estimated arrival times are typically updated while a flight is in the A state. Arrival gate, terminal, and baggage claim are often updated as well.
A flight can be marked with a status code of A once the flight leaves the gate. However, the flight is not truly Active until the flight leaves the runway. It’s not uncommon for a flight to sit on a departure runway for some time. If you’d like your application to be more precise, things to consider include:
actualRunwayDepartureDate - If there is a value for this field, then it is more likely that the flight is on the way
estimatedRunwayDepartureDate - If the estimated time is after the gate time, it most likely has accommodated for taxi time. However, if it is a long time after gate time, it usually means that the aircraft has been on the runway for a long time
Positional Information - We offer APIs that track the position of the flight. If these are updating, it means that the flight has departed
When we detect that the flight has arrived, the status code changes to L. This occurs when a flight has:
Landed on a runway, and the ActualRunwayDepartureDate was updated
A flight arrives at a gate, and the ActualGateDepartureDate is set
We get a status update from a source that indicates it has landed, even if no dates were updated
Arrival gate, terminal, and baggage claim are often updated in this state as well.
When one or more data sources indicate that a flight has been canceled, we use the status code C. This means that the flight has been canceled and is no longer scheduled to fly. This typically occurs when a flight is the S state, but not always. For example, a flight can depart the gate and sit on the runway for a long time before returning to the gate and being canceled.
When one or more data sources indicate that a flight landed at an airport different than the original destination, we mark the flight with D. If we are told what airport the flight landed at, the divertedAirport field is set, but this is not always the case.
The new destination could affect the traveler in several ways. Scenarios include:
A flight might return to the gate before leaving the runway. In this case, the diverted airport is the original departure airport
A flight might return to the original airport after takeoff. In this case, the diverted airport is the original departure airport
A flight might be scheduled to stop at a particular airport before continuing to another airport but decided to fly over the first airport. In this case, if the flight includes downline information you could detect a fly over.
A flight might temporarily land at an alternative airport due to a disruptive event and then depart to the original destination once the event is resolved. This might cause a new Flight Status record for the new flight to be created.
A flight might land at an alternative airport where arrangements are made to get the travelers to their original destination. At some point the aircraft will be moved without passengers, which might cause the creation of a new Flight Status record for the new flight. The information in the status updates and irregular operations data might help clarify this state.
The R code indicates that the flight is being redirected to another airport. Use caution when reporting this state, as it is not a true state like the other codes. Flights in R status usually don’t get redirected back to the original arrival. These are flight plan updates. It’s possible for the flight to be moved around the event, and be re-directed back to the original airport. However, a redirected flight that doesn’t get directed back will transition to diverted state upon arrival at the diverted airport.
A flight can be redirected even before it departs, so you shouldn’t assume that redirected means that the flight is on its way. The important thing to understand it that it’s a change to the original flight plan. When looking at flights with an R code, you should look for actual gate and runway times to determine if has departed or not.
The U code indicates we haven't determined the final status of a flight from a data source in a reasonable amount of time past the scheduled gate arrival time. We will still accept operational updates from data sources and might change the status from Unknown to another state such as Landed, Diverted, or Canceled if we detect further updates from data sources.
All flights should eventually end up in one of the final statuses of L, C, D, or U.
We collect a wide range of different gate and runway times. Depending on your application, some of these times probably have limited value. There's no guarantee that a flight will have all of these times defined. It depends on the data feeds available for the flight.
Flight status time
The published gate departure or arrival time provided by the airline. It’s unlikely that this will change. This is the time the flight is expected to pull back or arrive at the gate.
The most up-to-date scheduled gate departure or arrival time we have for the flight. It's initially the same as publishedDeparture and ArrivalGateDate if this record was created through a schedule import.
The most up-to-date estimated gate departure or arrival time we have for the flight. The estimated gate and runway times are always identical to the corresponding actual time if we have an actual time.
The most up-to-date actual gate departure or arrival time we have for the flight.
The departure and arrival runway times that were filed with the original flight plan for the flight.
The most up-to-date estimated runway departure, arrival, and takeoff times we have for the flight. When the flight plan is filed, these are the same as the flightPlanPlannedDeparture and flightPlanPlannedArrival times. However, they might be updated as the flight gets closer to departing. This information comes from various data sources, and isn’t as reliable as gate times. This is especially true for the departure time.
The most up-to-date runway departure or arrival times we have for the flight.
These are usually the published or scheduled gate times, but could be runway times if that's all we have. They’re usually the first dates that are received for the record, and used for search purposes.
The Cirium Flight Status structure might contain an additional array of data around irregular operations that provides additional insight and data that the normal structure doesn’t. This information is available only for flights that provide this additional data. These are time-based events, and a single flight might have multiple events recorded for it.
The event might also contain another flight status record ID if another flight is related to the irregular operation. For example, if a flight is diverted and then later departs, a new flight record might be created for it, connecting the new flight with the old.
The flight is canceled.
The flight was directed to land at a different airport than its scheduled destination. Information about the new airport is included if that information is available.
A continuation of a linked flight. Typically a continuation occurs when a flight is diverted to an alternate airport in order to get passengers to their scheduled destination.
A linked flight that is a continuation of the original. Typically, a continuation happens when a flight is diverted to an alternate airport in order to get passengers to their scheduled destination.
The flight isn’t expected to happen because the plane flying the route won’t stop at the specified departure airport. For example, suppose a flight is scheduled to go SEA to PDX to LAX. If the flight skips PDX and goes directly from SEA to LAX, then the PDX to LAX flight status record might have a flown-over irregular operation associated with it.
A flyover happens when a plane flying a route comprised of many stops skips one or more of the scheduled stops. For example, suppose a flight is scheduled to go SEA to PDX to LAX. If the flight skips PDX and goes directly from SEA to LAX, then the SEA to PDX flight status record might have a flyover irregular operation associated with it.
An irregular operation that doesn’t qualify as one of the other operations listed here.
A flight that was canceled for a period of time and subsequently reinstated to operational status.
A flight that was canceled or doesn’t operate might be replaced by another flight. Linking information for the new flight is provided.
A flight that replaced another flight. Linking information for the new flight is provided.
Return from airborne
The flight has taken off and must return to its original departure airport.
Return to gate
The flight backed away from the gate and started to taxi. But it doesn’t take off, and then returns to the gate.
Subsequent operation by
The flight returned to the original airport. The ID of a new flight operation record that is the continuation of the current flight record is identified. For example, suppose a flight with ID 100000000 was diverted but later continues to its destination with the ID of 10001010110. This describes a second attempt at the same operation.
Subsequent operation for
The ID of a flight operation that is the origin of the current flight record. For example, suppose a flight with ID 10001010110 was created based on the diversion of the flight with ID 100000000.
Removed from schedule
This only affects flight status when we don’t receive messages about the flight from any other source. In that case, where the record is removed from the schedule and no other source sends us any messages at all, after the scheduled arrival time, the flight is marked Canceled.
The updates we make to the Flight Status record are recorded in Flight Status Update structures and made available by our APIs. You need to specify includeDeltas in the API calls to see this information.
This information is an audit log and is useful for troubleshooting since it can help you understand why the general flight status record has a specific value. In addition, it might be valuable for advanced status applications. Some examples of what you can do with this information include the following.
The flight status record includes a structure that shows calculated departure, arrival gate, and runway delays. However, this information doesn’t tell you if the expected delay is increasing or decreasing. By parsing the updates to the record, you can show how often the estimated departure or arrival has been updated and whether the estimates are increasing or decreasing.
Was a recently departed flight canceled or diverted? A canceled flight just had an estimated departure updated. Is it about to be reinstated? A canceled or diverted flight just went to code A. This means it must have been reinstated, although it's hard to tell if there are passengers on board or if the airline is just moving the aircraft.
Suppose the arrival gate keeps toggling between “21” and “25.” This can mean that two data sources are in conflict. It might be worth presenting both to the user as an option.
A confirmed incident on a flight status record means there has been a problem. When this is reported, it's because a Cirium employee has manually published a message for the flight. If this happens, you should ignore all status codes, positional updates, gate times, runway times, etc. We'll send a message explaining the problem.
The Laminar Data Hub APIs provide a simple view into flight status information. The status of the flight is either:
The status transitions are defined by a set of rules shown in the diagram below.
Use FlightStats to track flights.
The FlightStats APIs provide a set of status and positional APIs by flight, airport, fleet, route, or area. They also include schedules, airline reference, airport reference, ratings, delay index, and weather information.
The Laminar Data Hub APIs provide a simple view into flight status information.