Methodology
How TravelTSA collects, verifies, and surfaces airport data.
Wait times are only useful if you trust them. This page documents exactly how TravelTSA produces the numbers you see on every airport card, how often they refresh, and what we do when a source breaks.
Six operating principles
What TravelTSA will and will not do
Source of record is the airport itself
Every live wait shown on TravelTSA is scraped from the airport's own public checkpoint page — the same page a staff member would point to if you asked where the number came from. We link back to it from each airport guide.
Refresh cadence: two minutes
The scraper runs on a two-minute loop. The envelope returned to the UI carries a per-airport last_updated timestamp. We surface it as a 'Refreshed N min ago' chip on every card so you can see exactly how current a reading is.
No numbers when the source is silent
When an airport publishes checkpoint hours instead of a numeric wait, we show the hours and label the card accordingly. When a source is down, we say so. We do not interpolate, fake, or crowdsource a number into the live view.
Staleness is visible
Readings older than 30 minutes are flagged as stale. Readings older than two hours, or sources that have failed three or more refresh cycles in a row, are explicitly labeled 'Reporting suspended' on the card.
Separate live signals from editorial content
Numeric waits only come from live scrapes. Airport guides, regional collections, and route advice are editorial — written by TravelTSA and updated on a slower cadence. We do not mix the two.
We monitor ourselves
A public status page surfaces per-airport scraper freshness. If a source goes dark or starts returning unusable HTML, it is visible to you at the same moment it is visible to us.
The pipeline
From airport page to your live board
- 1
Scrape
A source-aware scraper fetches the authoritative checkpoint page for each of the 27 tracked airports. Sources range from direct JSON endpoints to HTML-rendered tables. Each source has a dedicated parser and a per-source success rate budget.
- 2
Normalize
Raw strings are normalized into a common envelope: checkpoint name, lane type, wait minutes, status, and operating hours. Where a source publishes only hours-of-operation, the wait field stays null and the UI renders 'Hours only' rather than a fake number.
- 3
Cache
The normalized envelope is written to a server-side cache with a TTL (Redis when enabled for multi-instance setups; otherwise a coordinated in-memory store on the live cache task). Refreshes use a lock so we never run overlapping scrapes of the same source.
- 4
Serve
The frontend pulls the cache envelope on page load and on a modest polling interval while the tab stays open. The response carries timestamps we use to render freshness chips, advisories, and coverage labels on every airport card.
- 5
Monitor
Each refresh attempt records success, latency, and parser outcome. Sustained failures for a given airport flip the card to 'Reporting suspended' and the incident is visible on the public status page.
Coverage today
27 airports on the live board
We only add an airport when its source is stable and parseable on a repeating schedule. If an airport you expect is missing, it usually means we have not found a source we trust yet.
Full list on the airport directory. Live scraper health on the status page.