"We track your flight" describes a data subscription, not an outcome. What matters operationally is which of three different times the system is reading, how often it refreshes, and — above all — whether a change produces a notification to a human who can act. Tracking that updates a screen nobody is watching has no effect on whether your car is there.
Flight monitoring is the most advertised and least examined feature in airport transportation. Almost every operator claims it. Very few can describe what their system does when a flight moves, which is the only question that matters.
Scheduled, estimated, actual: three different numbers
A flight has at least three arrival times, and confusing them is the most common cause of a car being in the wrong place.
| Time | What it is | Operational use |
|---|---|---|
| Scheduled | The published timetable arrival. Fixed months ahead, and frequently wrong on the day. | Only for initial planning at the moment of booking. |
| Estimated | The airline's current projection, revised as the flight progresses. | The number dispatch actually plans against. |
| Actual | Wheels down, or block-in at the gate — which are not the same event. | Starts the curb-time estimate; too late to plan with. |
The distinction between wheels down and block-in at the gate is worth a sentence of its own. Landing is public and immediate. Reaching the gate can be ten minutes later, or considerably more if a gate is occupied. A system that treats wheels-down as arrival will consistently be early, and at a busy airport that means a vehicle cycling around the terminal.
Where the data comes from
Operators do not read flight boards. They consume a feed, and there are broadly three tiers:
- Airline and airport data via a commercial aggregator. The serious option. Delivers estimated times, gate information, diversions and cancellations, usually with a webhook or a poll interval measured in minutes.
- A free or low-cost public API. Workable, generally coarser, often slower to reflect changes, and frequently rate-limited in ways that matter precisely when many flights are moving at once — which is exactly when you need it.
- A person checking a website. Common in small operations, and entirely dependent on someone remembering. This is what "we monitor your flight" means more often than the industry likes to admit.
The tier is invisible from the outside, which is why the useful diagnostic question is behavioural rather than technical — see what to ask below.
The refresh interval matters more than the feed's marketing. We learned this on an early-arriving flight: the data was correct, our poll interval was not aggressive enough near the arrival window, and the passenger reached the curb before our estimate had caught up. The fix was not a better feed. It was polling harder as the arrival window approaches and treating any change inside the final hour as an event rather than a refresh.
The gap tracking cannot close
Here is the limitation that no flight data solves: the feed tells you about the aircraft, and you are waiting for a person.
Between the aircraft reaching the gate and the passenger reaching the curb sit deplaning, immigration and customs on international arrivals, baggage delivery, and the walk. That interval is highly variable, it is not in any flight feed, and on an international arrival at a busy hour it can exceed the total flight delay you were tracking so carefully.
Operations close that gap with the passenger, not with data:
- Flight data gets the vehicle staged near the airport at roughly the right time.
- A signal from the passenger — a message, a call, a tap — releases the vehicle to the pickup point.
Any operation that skips step two is guessing at the most variable part of the journey. This is why the passenger's phone number is an operationally load-bearing field, as covered in how dispatchers coordinate an airport pickup.
Tracking is worthless without notification
This is the whole argument of the article, so it gets stated bluntly: the deliverable of flight monitoring is not data, it is a notified human.
A system that ingests an updated estimate and renders it on a dashboard has performed a technical function and no operational one. At 4am there is nobody looking at the dashboard. The chain has to complete:
- The estimated time changes by more than a threshold.
- The system identifies which live reservations are affected.
- It notifies the specific person responsible for those reservations, through a channel that interrupts — push notification, SMS, a call for severe changes.
- The message states what changed and what decision is required, not merely the new number.
- The person's response is recorded against the trip, so the next person to look knows it was handled.
Step three is where most implementations stop, and step five is the one almost nobody builds. Without it, two staff handle the same exception twice, or each assumes the other did.
The threshold in step one is a real design decision, not a detail. Too tight and dispatch is flooded with noise on every two-minute revision, learns to ignore alerts, and misses the one that mattered. Too loose and a forty-minute early arrival passes unremarked. Our own approach is asymmetric: early arrivals get a much tighter threshold than delays, because a delay gives you time and an early arrival takes it away.
The cases that break naive tracking
- Diversion. The flight lands at a different airport. The tracked flight completes successfully and the passenger is 90 minutes away by road. Systems that treat "landed" as "arrived at the booked airport" report a successful arrival while the trip silently fails.
- Cancellation and rebooking. The watched flight ceases to exist and a new, unwatched flight appears. No amount of monitoring the old flight number helps.
- Codeshare and flight-number changes. The passenger books under one carrier's number and travels on another's. Resolving the wrong number produces confident, wrong data.
- Date rollover. A red-eye booked as arriving on the departure date. The system resolves a flight on the wrong day — sometimes a real flight, which is worse than none.
- Terminal change. The aircraft arrives where the vehicle is not staged. More disruptive at large multi-terminal airports than any modest delay.
- Multiple passengers, separate flights. One reservation, two arrivals, and the trip is governed by the later one — which a system watching a single flight number cannot know.
Each of these is a validation problem at booking time as much as a monitoring problem at flight time. Resolving the flight number against real schedule data while the customer is still on the phone catches the mistyped number, the wrong date and the codeshare mismatch, when they are still cheap to fix. That principle generalises, and it is the subject of the booking and pricing errors that cost operators the most.
What to ask before you rely on it
Whether you are a traveller choosing an operator or an operator evaluating software, the same three questions separate real monitoring from a claim:
- "If my flight is delayed two hours at 1am, who finds out, and how?" A good answer names a person or a role and a channel. A vague answer about the system handling it means a dashboard.
- "What happens if I arrive forty minutes early?" This tests the asymmetry. Operators who have genuinely thought about monitoring treat early arrivals as the harder case.
- "What do you need from me on arrival?" An operation that closes the data-to-curb gap with the passenger will have a clear answer. An operation that says "nothing, we track everything" is relying on flight data to predict baggage claim, which it cannot do.
For how this fits into the full arrival sequence, see how an LAX transfer is coordinated, step by step.
Sources
Questions we actually get asked
If the company tracks my flight, do I still need to tell them about a delay?
If the delay is in the airline's data, no — an operation worth booking already has it. Tell them about anything the data cannot see: you were rebooked onto a different flight, you are stuck at immigration, your bag did not arrive, or you are travelling with more luggage than expected.
Those are the situations that actually cause problems, and none of them appear on a flight tracker.
What happens if my flight is cancelled entirely?
Operationally this is a re-booking, not a delay, and it is the one case where tracking is least helpful — the old flight simply stops existing. A rebooking onto another flight creates a new arrival that no system has been told to watch.
Contact the operator with the new flight number as soon as you have it. On the commercial side, what happens to your money depends on the terms recorded when you booked, which is why cancellation terms belong in the reservation record rather than in a verbal assurance.
Does flight tracking cost the operator anything?
Yes, and that is worth knowing, because it explains why some operators do not really do it. Commercial flight data is licensed, and pricing typically scales with how many flights you watch and how often you poll them. An operator checking a free public tracker by hand is technically "tracking flights" and operationally doing something quite different.