When a storm parks itself over Chicago or fog socks in San Francisco, flights don't just "get delayed" — the FAA runs specific, named traffic-management programs to keep the system from overloading. Ground stops, ground delay programs, closures, and airspace flow programs each work differently, hit different flights, and change with little notice. If you're building an operations dashboard, a departure board, or passenger alerts, you need to know what each program means and how to pull them live. This post explains the four program types and shows how to get them by API.
Why these programs exist
An airport (or a chunk of airspace) has a finite acceptance rate — how many aircraft it can safely take per hour. Weather, runway configuration, and equipment outages all cut that rate. When demand exceeds the reduced supply, the FAA's Air Traffic Control System Command Center steps in and meters traffic using Traffic Management Initiatives (TMIs). Instead of letting aircraft launch and then stack up in holding patterns burning fuel, the programs hold the delay on the ground, where it's safe and cheap. The four you'll encounter map cleanly onto four fields in the data.
The four program types
| Program | Code | What it does |
|---|---|---|
| Ground Delay Program | GDP | Meters arrivals into a constrained airport by assigning each inbound flight a controlled departure time |
| Ground Stop | GS | Halts departures to a specific destination entirely, for a defined window |
| Closure | — | The airport or a facility is closed or restricted outright |
| Airspace Flow Program | AFP | Meters traffic through a congested en-route region, not a single airport |
Ground Delay Program (GDP) is the workhorse. When an airport can't accept its scheduled arrival demand, the FAA issues each inbound flight an Expect Departure Clearance Time (EDCT) — a wheels-up slot calculated so arrivals land at the reduced rate. Flights wait at their origin gate, not in the air. GDP data typically comes with an average and maximum delay (e.g. "34 minutes" average, "1 hour and 25 minutes" max).
Ground Stop (GS) is more severe and more sudden. Rather than metering, it stops all departures headed to the affected airport for a window — used when conditions collapse fast (a thunderstorm over the field, a runway incident) and even metered arrivals can't be accepted. Ground stops often precede or upgrade into a GDP.
Closure is exactly what it sounds like: the field or a facility is shut, frequently carrying the underlying NOTAM text as its reason.
Airspace Flow Program (AFP) is the one people misread. It doesn't belong to an airport — it constrains an en-route volume of airspace (managed by an ARTCC, an en-route control center) that many flights transit. So AFP rows are keyed by a facility, not an airport code, and can affect flights that aren't landing anywhere near the constrained area. Label them distinctly in your UI.
Getting FAA delays by API
SkyLink API's FAA delays endpoint returns all four program types in a single envelope. The nationwide feed is a plain GET with no parameters:
curl "https://skylink-api.p.rapidapi.com/delays/faa" \
-H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
-H "X-RapidAPI-Host: skylink-api.p.rapidapi.com"{
"ground_delays": [
{
"airport": "KSFO",
"reason": "low ceilings",
"avg_delay": "34 minutes",
"max_delay": "1 hour and 25 minutes"
}
],
"ground_stops": [],
"closures": [
{
"airport": "KJFK",
"reason": "!JFK 06/158 JFK AD AP CLSD TO TRANSIENT GA ACFT ...",
"begin": "Jun 11 at 16:30 UTC.",
"reopen": "Jul 22 at 03:59 UTC."
}
],
"airspace_flow_programs": [],
"total_alerts": 8,
"message": null
}The response always contains all four arrays (ground_delays, ground_stops, closures, airspace_flow_programs), even when some are empty — so you can render each section without guarding for missing keys. To decorate a single airport's departure board, hit the per-airport variant, which filters to that field (and still includes relevant AFP rows, since en-route programs can affect it indirectly):
curl "https://skylink-api.p.rapidapi.com/delays/faa/KJFK" \
-H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
-H "X-RapidAPI-Host: skylink-api.p.rapidapi.com"
Four things to build in from the start
These programs are volatile and US-specific, and the data has a few sharp edges worth handling up front:
- US coverage only. This is the FAA's National Airspace System — continental US, Alaska, Hawaii, and US territories. For international delay context, combine it with flight status and airline ops data.
- Empty is a valid answer.
total_alerts: 0with amessagestring means "no active programs right now" — a normal fair-weather response, not an error. Don't surface it as a failure. - Cache for minutes, not hours. Ground stops appear and lift with little notice; cache responses no longer than 2–5 minutes or you'll show a program that's already been cancelled (or miss one that just started).
- Durations are human-readable strings.
avg_delayandmax_delaycome as text like"34 minutes"— display them as-is or parse conservatively; don't assume a numeric type.
Where this fits
FAA delay programs are the upstream signal in a delay pipeline: a GDP or ground stop appears before individual flights show updated times, so polling this endpoint gives you an early warning that a whole airport is about to slip. That's why it pairs so well with per-flight tracking — merge these program-level alerts with live flight status and schedules to explain why a board full of flights just went red. If you're building the alerting layer, our flight delay notification system walk-through shows how to turn these signals into timely passenger notifications.
SkyLink API gives you a free tier of 1,000 requests/month to build against, with paid plans starting at $18.59/mo once you're handling production traffic. It's available through the free trial — sign up, grab a key, and pull live FAA ground stops, delay programs, closures, and flow programs in one call.