| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Phase | Airport | Scheduled | Estimated | Actual | Delay | Copy |
|---|---|---|---|---|---|---|
| {{ row.phase }} | {{ row.airport }} | {{ row.scheduled }} | {{ row.estimated }} | {{ row.actual }} | {{ row.delay }} |
| # | Flight | Status | Departure | Arrival | Delays | Copy |
|---|---|---|---|---|---|---|
| {{ row.rank }} |
{{ row.route }}
|
{{ row.status }} |
{{ row.dep }}
{{ row.depAirport }}
|
{{ row.arr }}
{{ row.arrAirport }}
|
{{ row.delay }} |
Flight delay is the gap between when an aircraft was supposed to move and when it is now expected or known to move. That gap affects more than the departure board. It changes when you leave for the airport, whether a connection is still realistic, when a pickup should happen, and how much trust to place in a schedule that looked settled an hour earlier.
This tracker turns that moving picture into a readable status view for one flight on one travel date. It pulls flight data from the selected provider, normalizes the response into a common structure, and then shows the status summary, route, departure timing, arrival timing, and matching records in separate views that are easier to compare than a raw API payload.
That makes the page useful for travelers, pickup coordinators, dispatch staff, and anyone who needs a quick answer to a practical question such as whether a flight is still on time, whether a delay is growing, or whether an arrival is recovering enough to keep a handoff plan intact. It is especially helpful when the same flight number can return several matches and you need to sort out the right leg by route and date before acting on the result.
Departure delay and arrival delay should not be treated as interchangeable. A late pushback can shrink in the air, while a flight that left on time can still arrive late after congestion, weather, or gate constraints. Looking at both ends of the trip gives a better sense of whether the disruption is operationally minor or whether it is likely to change the decision you still need to make.
The page is still a status aid, not the airline's own control system. Public feeds can disagree, timestamps can be revised, and cancelled or diverted flights may change shape abruptly. For important choices such as rebooking, crew planning, or a time-sensitive pickup, treat this as a fast comparison tool and confirm critical actions with the operating carrier.
The most important input is the flight's local departure date. Flight numbers repeat every day, and some providers return nearby or related records if the match is loose. If the date is wrong, even a correct flight number can produce a believable but irrelevant record. In practice, the date is what keeps the rest of the interpretation anchored.
The provider choice changes how the lookup reaches the data, but the page tries to keep the result shape consistent after the response arrives. AeroDataBox is wired through RapidAPI headers and tends to be the smoother browser-side option in the shipped interface. Aviationstack uses an access key in the query string and can be routed through an optional proxy prefix when browser policy or account setup makes a direct request less practical.
The match controls matter when a flight number is shared across code-share listings or when a carrier publishes close variants. Exact-first matching keeps the result list anchored to the entered number and then falls back to broader matches only when needed. Relaxed matching is more useful during discovery, especially when you are unsure whether the visible number is the marketing code or the operating code.
The cancellation and code-share switches are not just cosmetic filters. They change which records survive the normalization step, which can materially change the list you compare in the Matches view. If you are trying to locate the primary operating flight, hiding code-share variants can reduce noise. If you are tracing what a passenger actually sees on an itinerary, leaving them visible is often the better choice.
Sample mode is useful when you want to understand the output shape before spending a live token or when you need to demonstrate the page without making a network call. The sample record is synthetic, so it is not evidence about a real flight, but it does show how status, timeline, exports, and route selection behave once a result set is present.
The package runs in the browser and has no tool-specific server helper in this bundle. A live lookup sends a request either to Aviationstack's /v1/flights endpoint or to AeroDataBox's flight-by-number endpoint, depending on the selected source. After the response returns, the page converts provider-specific fields into a shared flight object with airline identity, route, departure and arrival sections, an aircraft label, raw source payload, and package-level status fields.
Delay calculation follows a simple precedence rule. If the provider supplies a numeric delay value for a movement section, that value is used directly. If not, the package compares the scheduled timestamp against the actual timestamp when present, or against the estimated timestamp when actual timing is still missing, and rounds the difference to whole minutes. That is why a record can still show a meaningful delay even when the provider does not expose a dedicated delay field.
Status badges combine provider wording with package rules. Text containing cancellation wins immediately, diversion is treated as a severe disruption, and landed or arrived status is surfaced separately from an in-progress delay state. For flights still in scheduled, active, or en-route phases, the page promotes anything above a small slip into a delayed label so you can see deterioration before it reaches the more obvious thresholds that matter for connection planning.
The result views are built for different questions. Flight status is the concise record for one chosen leg. Timeline places scheduled, estimated, and actual moments side by side for departure and arrival. Matches helps you resolve ambiguity when several rows are returned. JSON exposes the normalized flight objects so you can inspect or export the same structured data the page is using internally.
| Category | How the page assigns it | What it usually means for planning |
|---|---|---|
| On time | No disruption keyword and only minor schedule variance | Useful for rough pickup timing, but still worth refreshing later |
| Delayed | Meaningful positive delay or an active record with a growing slip | Recheck before leaving, especially for short connections |
| Diverted / Severe delay | Diversion wording or very large delay minutes | Expect major operational change and verify with the carrier |
| Cancelled | Status text contains a cancellation indicator | Treat itinerary impact as immediate until the airline says otherwise |
| Landed | Status text shows the flight has already arrived | Focus on arrival timing, gate, and baggage details when present |
Time display is localized for readability. When a provider supplies an airport time zone, the formatter uses that zone for the rendered clock value. This matters because a late-night departure, a transatlantic arrival, and a connection check can look deceptively simple until you realize the times belong to different local contexts.
The privacy behavior is deliberately split. The ordinary lookup parameters are synchronized through the shared query-parameter mechanism, which makes result links reproducible. The API key and optional proxy prefix are handled separately in browser session storage and are intentionally excluded from the share URL. Exports stay local to the browser through CSV, DOCX, and JSON download paths.
Timeline to compare scheduled, estimated, and actual moments side by side.Matches when more than one row appears, then select the exact leg you want to inspect.The first interpretation check is identity, not delay. If the airline, route, or travel date looks wrong, stop before reading the minute values. A believable delay number attached to the wrong leg is still the wrong answer, and code-share traffic is one of the easiest ways to fall into that mistake.
Once identity is settled, compare departure and arrival together. A flight can leave late and arrive closer to schedule if it recovers time in the air. The reverse can also happen when airborne holding, congestion, gate unavailability, or arrival sequencing adds delay after an apparently orderly departure. The route view tells you where the leg belongs. The timeline tells you whether the disruption is expanding or shrinking.
Provider wording deserves context. Active, scheduled, and landed describe different operational phases, while the package-level badges translate those phases into a practical scan language. That translation is useful for quick reading, but it should not be mistaken for an official airline incident classification or a passenger-rights judgment.
If one source looks implausible, compare again rather than over-trusting the freshest timestamp. Public feeds can lag, a gate may be missing even after arrival, baggage details can appear late, and a cancellation may surface in one source before another. The page is strongest when used as a fast comparison layer over live provider data, not as a final authority on operational intent.
Pickup timing for an arriving passenger. A friend sends a flight number and asks for a pickup. You fetch the record for the correct departure date, select the matching route, and compare scheduled versus actual arrival. If the arrival delay has narrowed while the flight is already active, you leave later than planned but do not assume the original arrival board is still accurate.
Connection risk check. A traveler wants to know whether a short onward connection is still realistic. The status summary shows only a moderate departure delay, but the arrival side is slipping harder than the departure side. That difference is the useful signal, because it suggests the arrival airport side of the trip is under more pressure than the departure gate view alone would imply.
Code-share cleanup. A search returns several rows that all look related. You keep code-shares visible long enough to compare airline names and route labels, then switch to the exact leg that matches the intended itinerary. This prevents you from tracking a marketing code while the actual operating record is the one carrying the timing changes you care about.
Live lookups need the token expected by the selected provider. Without one, the shipped page can still show sample data so you can inspect the result structure and export paths.
Flight numbers can appear in code-share listings, repeated services, or close variants. The page therefore exposes a match list so you can confirm the correct route and date before treating a row as definitive.
No. The package keeps the API key and optional proxy prefix out of the URL and stores them only in browser session storage for the current session.
Not always. Arrival status can be settled while gate, baggage, or final operational details are still catching up across data sources.
No. It reports status and timing information. It does not determine legal eligibility for compensation, refunds, or rebooking entitlements.