The Transportation Security Administration’s MyTSA mobile app has seen a sharp rise in downloads as travelers seek real-time checkpoint information ahead of busy travel periods. But a growing number of users are discovering that several of the app’s core features, including wait-time estimates and checkpoint data, are not functioning reliably. The gap between what the app promises and what it actually delivers points to deeper technical and funding problems that TSA has not publicly addressed.
What the App Promises Travelers
MyTSA is designed to be a one-stop travel companion for anyone passing through a TSA checkpoint. According to the agency’s official app page, the software offers the ability to check delay information, provides estimated checkpoint busyness based on historical data, and integrates with AskTSA, the agency’s customer service channel. Travelers can also look up whether specific items are permitted in carry-on or checked bags, a feature that has long been among the app’s most popular tools.
The app is free and available on both the App Store and Google Play, as confirmed in TSA’s download guidance. A DHS Privacy Impact Assessment notes that MyTSA is built to operate without collecting personally identifiable information while still offering capabilities including item lookup, checkpoint policy information, and crowdsourced wait times. That privacy-first design likely contributed to the app’s appeal, especially among travelers wary of sharing data with third-party alternatives that may monetize their information.
Backend Systems Show Signs of Neglect
The technical architecture behind MyTSA tells a less reassuring story. The app relies on a set of web service endpoints to pull live and historical data. Archived API documentation from DHS lists specific endpoints, including one called “GetConfirmedWaitTimes.ashx” for retrieving checkpoint wait times and another called “GetAirportCheckpoints.ashx” for airport and checkpoint metadata. These endpoints depend on TSA-hosted XML metadata files to function correctly and to translate raw submissions into meaningful outputs for travelers.
One of those files, known as apcp.xml, serves as the canonical dataset for airport and checkpoint details and is used to interpret the app’s wait-time outputs. It includes distinctions between airport-level and checkpoint-level data, meaning any staleness in this file could cause the app to display outdated or incomplete information, such as listing closed checkpoints or missing newly opened ones. A companion file, apcp checksum, exists specifically to signal when the main dataset has changed, allowing developers and automated systems to verify whether updates are flowing through the pipeline.
The fact that the API documentation now sits in an archived section of the DHS website raises questions about whether the agency is actively maintaining the backend infrastructure that powers the app. Archived status typically signals that content is no longer being updated, which would be consistent with reports of stale data reaching users. If the metadata files are not refreshed in tandem with real-world changes at airports, even a perfectly coded mobile app would end up presenting misleading information.
A Federal Funding Lapse Compounds the Problem
The timing of these technical issues aligns with a broader disruption across DHS digital operations. A DHS notice dated February 17, 2026, described how a lapse in federal funding affected the department’s web and social media work, including the staffing and maintenance behind official online platforms. While the notice did not single out MyTSA by name, the app falls squarely within the category of DHS-maintained digital services that would be affected by reduced staffing and suspended updates during a funding gap.
This connection matters because the app’s usefulness depends entirely on fresh data. Crowdsourced wait times lose value if the system collecting and distributing them is not actively monitored. Historical busyness estimates become misleading if the underlying datasets no longer reflect current airport configurations, checkpoint closures, or staffing changes. A funding lapse that freezes backend maintenance does not just pause improvements; it degrades the product travelers are already relying on and can leave them planning around numbers that no longer match reality on the ground.
The Long Arc of MyTSA’s Data Challenges
Struggles with wait-time accuracy are not new for the TSA. The agency has promoted MyTSA during peak travel seasons for years, including in a 2018 travel blog offering spring break tips that highlighted the app as a planning tool. The DHS Privacy Impact Assessment for the app, which includes documents from both 2010 and a 2017 update, shows that the agency has been aware of the need to balance data collection with privacy for well over a decade and has repeatedly framed MyTSA as a way to help passengers anticipate checkpoint conditions.
Yet the core challenge has persisted: TSA does not directly measure wait times at most checkpoints using sensors or automated systems. Instead, the app has historically relied on a mix of crowdsourced user reports and historical averages. That model works only when enough travelers submit data and when the system processing those submissions is running properly. When either condition fails (because participation drops, servers are not monitored, or data pipelines fall out of sync), the app’s wait-time feature becomes little more than a guess dressed up as an estimate.
Most coverage of MyTSA treats the app as a simple consumer product, but the real issue is structural. TSA built a data pipeline that requires continuous feeding and maintenance, then subjected it to the same budget uncertainties that affect every other federal digital service. The result is a tool that works well enough during periods of stable funding and active development but degrades quickly when either is interrupted. Because the problems are largely invisible to end users, travelers may not realize that the numbers they see are based on stale or incomplete data until they arrive at a checkpoint and find a very different reality.
What Travelers Should Actually Expect
For anyone who recently downloaded MyTSA expecting reliable checkpoint wait times, the reality is more limited. The app’s item-lookup feature and AskTSA integration appear to function independently of the wait-time data pipeline, so travelers can still check whether a snow globe, a bottle of hot sauce, or a specialty tool will clear security in a carry-on bag. Those reference functions rely on relatively static policy information that does not need constant updating and is less vulnerable to short-term funding disruptions.
By contrast, the wait-time and busyness features, which are arguably the main reason many people download the app, should currently be treated as rough guidance at best. If the underlying airport and checkpoint metadata are out of date, the app might mislabel which checkpoints are open or misjudge how passenger volume is distributed across terminals. If crowdsourced submissions are not being ingested or validated consistently, the “real-time” component becomes little more than a sporadic sampling of traveler reports, skewed toward airports and times of day when tech-savvy passengers happen to participate.
Travelers can still use MyTSA as part of their planning toolkit, but they should calibrate their expectations. The app remains useful for confirming what can go in a carry-on, reviewing basic security rules, and accessing customer service channels. For timing their arrival at the airport, however, passengers may be better served by combining the app’s estimates with other signals: airline guidance, airport websites, and their own experience with local checkpoint patterns. Until TSA invests in more robust, actively maintained data infrastructure, and insulates that infrastructure from the stop-and-start cycle of federal funding, MyTSA’s most ambitious promises will continue to outpace what it can reliably deliver.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
