FAA flight ground stop map shows how to track disruption

A public map tracked U.S. aircraft during the FAA’s nationwide ground stop on Friday, November 13, 2026, combining community flight data with airport status information. For developers, it’s a useful example of building an incident view from independent data sources, and of being explicit about what a metric can and cannot tell you.

#What happened

A project posted to Hacker News’ Show HN, grounds.top, displayed aircraft positions and airport recovery information during the stop. Its flight positions came from the adsb.fi community ADS-B network, while its airport delay feed used FAA NAS Status. The page described itself as independent and unofficial, and said it was not affiliated with the FAA.

The map let visitors hover over or tap aircraft markers to identify planes. Alongside the map, it showed the estimated shutdown timeline, airport-level departures and recovery, aircraft airborne by carrier, and a section for news reports updated by hand.

The airport recovery view compared departures in a 30-minute period with the same half-hour a week earlier. It counted an airport as recovered after departures reached at least three-quarters of that baseline for two consecutive readings. The backlog view estimated missed commercial departures by subtracting this week’s observed departures from the count for the corresponding hours a week earlier.

That distinction matters: these are comparisons derived from tracking data, not official FAA totals. The FAA delay feed lists airports with specific entries, but the map warned that a nationwide stop affects airports whether or not they appear in that feed.

#Why it matters

The interesting engineering choice is the combination of sources with different roles and levels of authority. ADS-B data supplies a view of aircraft positions. The FAA feed supplies airport delay entries. Hand-updated reporting adds context that neither feed is intended to provide. Putting those pieces together makes a practical incident dashboard, but it does not turn the dashboard into an official record.

For engineers building operational tools, this is a familiar problem. A service outage rarely comes with one complete, clean event stream. You may need to join telemetry, status pages and human updates, then give users enough context to understand where each claim came from.

The map’s comparisons also show why a dashboard needs visible definitions. “Recovered” sounds definitive, but here it means a specific threshold against the same time the previous week, sustained for two readings. That’s more useful than a vague green status, while still leaving room for caveats: the previous week may not represent a typical day, and a departure count alone can’t describe every passenger’s situation.

The people affected include travelers trying to understand whether flights are moving, airline and airport staff monitoring recovery, and developers or analysts who need an overview beyond a list of delay notices. A clear independent view can help users interpret a fast-changing situation. It should not be mistaken for instructions from an airline or the FAA.

#What it means for you

If you build dashboards or incident tooling, the project offers a few practices worth applying this week:

• Label each data source. Show whether a value comes from a community network, a government feed or a human update. Users need to know what they’re looking at before they rely on it.
• Explain derived metrics beside the number. State the baseline, time window and recovery rule. “75% of the same half-hour a week earlier for two readings” is interpretable; “mostly recovered” isn’t.
• Design for incomplete feeds. A missing airport entry is not proof that the airport is unaffected. Distinguish “no reported entry” from “no disruption.”
• Keep live data and editorial context separate. If humans update a news section by hand, label it and show when it was last updated. Don’t imply that manually maintained context refreshes at the same rate as aircraft positions.

The project’s flow can be understood as three inputs feeding a dashboard, with the dashboard calculating comparisons from the tracking data:

flowchart LR
    A["adsb.fi aircraft positions"] --> D["grounds.top dashboard"]
    B["FAA NAS Status delay feed"] --> D
    C["Hand-updated news reports"] --> D
    A --> E["Departure and recovery estimates"]
    E --> D

#The bigger picture

This page is a small example of public-interest data tooling built around existing sources rather than a single authoritative API. That can be a sensible approach when the sources serve different purposes: flight tracking can show aircraft activity, while an airport status feed can report specific delays. The dashboard’s job is to make those views easier to interpret, not to erase their differences.

That approach comes with operational trade-offs. Community tracking coverage, feed update timing and manual editorial work can all affect what a visitor sees. The source text doesn’t specify the map’s refresh interval, hosting setup or data-retention policy, so those details shouldn’t be assumed. For builders, the lesson is to make update times and limitations visible rather than implying complete coverage.

The project also drew attention on Hacker News, where the Show HN post had 150 points and 21 comments when reported. That’s a signal of interest in the tool, not evidence that its estimates were independently validated. A useful next step for any similar project would be to document data freshness and compare estimates with official figures once those are available.

#Key takeaways