Data status

When this was read. The state could not be read when this page was rendered (2026-11-06 06:46 UTC): No check of this dataset has been recorded yet. Every dataset is shown as unknown, and none as in step. Today: 38 unknown — could not be read.

The five states. In step: the upstream was fetched inside its window, its shape held, and it matches what we hold. Changed upstream: the authority has published something we do not hold yet — a known difference waiting for a reviewed refresh, not an error; for a source edited every day, such as the airport list, this is its normal state between refreshes. Schema drift: the upstream no longer has the shape our check knows, so no comparison was attempted. Unreachable: at the last check the upstream did not answer, answered with an error, or served an error page or a truncated file — never read as “no change”. Window missed: no successful check inside the dataset’s declared window (seven days for a source watched daily). Unknown means the state itself could not be read; it is never shown or served as in step.

What an answer carries. Every API answer drawn from one of these datasets carries the same state: on the response envelope (?envelope=1.2, and every MCP tool result) under _meta.upstream, and on every REST answer in the X-FreightUtils-Upstream header. It names each dataset the answer was drawn from with its state, how it is watched, the last successful check and the window, and stale, which is true only when a dataset missed its window. A stale answer is still served, from the last verified edition we hold. A caller who would rather be refused can add ?if_stale=refuse to a REST request and gets HTTP 424 with the reason instead, only while a dataset of that answer is in a missed window. One unreachable check never makes an answer stale, and neither does a state we cannot read.

What this page does not show. It does not say that any answer is right: a dataset in step can still hold an error, and our Methodology and Coverage pages say how each is verified. It does not show an authority’s own outage history, only what our last check found. A changed upstream is a difference we know about, not a fault in what we serve. Datasets with no upstream of their own — curated sets compiled from manufacturers’ and carriers’ specifications, or tables derived from another dataset — are checked by their file’s checksum and a review or edition-check cadence, and say so. Some upstreams cannot be read by the site’s own check (one authority’s firewall refuses every script but one tool; one is checked by a person); each row says which, and its state is drawn from the upstreams that were read.

Where the state comes from

Once a day the site fetches each watched upstream, rejects an error page or a truncated file before reading it, validates the upstream’s shape against the one we recorded, and compares it with what we hold — record by record for the airport list and the HS chapters and sections, publication by publication for the notification and release lists. The same state is on Coverage and, as JSON, in /api/coverage under upstream. A separate daily watch alerts us when a person is needed. This page is reference information about our data, not legal advice.

in_step — In step — the upstream was checked inside its window and matches what is heldchanged_upstream — Changed upstream — the authority has published a difference that is not held yetschema_drift — Schema drift — the upstream no longer has the shape the check knowsunreachable — Unreachable at the last check — the upstream did not answer, or answered with an error pagewindow_missed — Window missed — no successful check inside the declared window; answers are marked staleunknown — Unknown — the state could not be read