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 or stops publishing numeric waits.
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: every 3 minutes
The scraper runs every 3 minutes. The envelope returned to the UI carries per-airport timestamps. We surface freshness chips 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
Fresh under 6 minutes, watch at 6-11 minutes, stale at 12 minutes. When a source is not publishing numeric waits, the UI says hours-only, not-reporting, suspended, or unavailable instead of guessing.
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 label those surfaces differently from live source-backed values.
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.
Data boundaries
Three different signals, kept separate
TravelTSA combines live airport data with planning context, but those signals do not carry the same level of certainty. The interface is designed to label the difference before you act on it.
Live airport waits
Source-backed checkpoint minutes, source-side hours, or source-unavailable states from official airport pages.
Editorial airport context
Terminal notes, route tradeoffs, airport access friction, and guide copy maintained by TravelTSA.
Route-level fare context
Comparable itinerary snapshots for the route and date. They are not fares for the exact matched flight and do not guarantee bookability.
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. The public interface treats airport timestamps at or beyond 12 minutes as stale and separates scrape failures from hours-only or not-reporting sources.
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.