NYC Subway Status — Live Delays in Plain English
Updated every minute from the MTA service alerts feed. Last refresh: 11:34 AM ET.
IRT (numbered lines)
BMT
IND
Shuttles
Staten Island Railway
About this tool
Every NYC subway rider has the same question at some point during the week: "is my train running, and if not, should I leave now and try anyway or take a different line?" The MTA itself answers it on new.mta.info, but the official page is heavy, ad-laden, and slow to load on a crowded platform with one bar of LTE. This tool's job is to be a faster, cleaner alternative that uses exactly the same underlying data — and tells you honestly what that data does and doesn't mean.
Where the data comes from
The status grid on this page is computed from MTA's GTFS-Realtime service-alerts feed — the same feed that powers new.mta.info's own service status box. We fetch the feed every 60 seconds, cache it in Vercel KV, and apply MTA's published "Service Status Box" algorithm to project the alerts onto a per-route badge. The full sourcing and field-by-field algorithm notes live on the subway methodology page.
The short version: each alert in the feed names one or more route IDs (via InformedEntity.route_id) and carries a sort_order integer indicating severity (Delays = 22, Suspended = 39, etc.). For each route, we find all alerts that name it and are currently active, then pick the one with the highest sort_order. That alert's alert_typestring becomes the route's status badge. Six internal status buckets cover the full range of MTA editorial strings: no-active-alerts, planned-work, service-change, delays, station-notice, and suspended.
What "no active alerts" does and doesn't mean
A green "no active alerts" badge means MTA hasn't published an alert against that route in the time window we're reading. That's not the same as "every train is running exactly on schedule." The official MTA documentation explicitly notes that minor service disruptions don't always have alerts attached: "There can be minor service disruptions that don't have alerts associated with them." We follow MTA's own recommendation to call this state "No Active Alerts" rather than "Good Service" — being accurate about what we're actually claiming matters more than feeling reassuring.
On the other end of the spectrum, a red "Suspended" badge is a high-confidence signal that trains aren't running on at least part of the route. Suspended-class alerts win the sort_order race against anything else, so they'll be the badge state even when delays and station notices are also active. The header text on the alert (visible on the line drill-down) typically specifies which segment.
What this tool deliberately doesn't do
Four categories of subway questions are intentionally out of scope:
Countdown clocks."Next 1 train in 4 minutes" is a different data product — it requires parsing per-station trip updates across seven separate GTFS-Realtime trip feeds, one per route group, and merging them with the static schedule. The official MyMTA app, Citymapper, and Transit App all do this well and own that space. This tool answers a coarser question ("is it broken right now?") and skips the trip-update complexity entirely.
Trip routing."Should I take the F or the M to Bryant Park?" needs full graph routing over the static GTFS plus trip-update merging — again, covered by the major routing apps. Not the question this tool answers.
Elevator and escalator alerts. Those live in a separate MTA feed (nyct/nyct_ene*.json) and don't appear in the service-alerts feed we read. Accessibility-specific alerts are out of scope for v1.
Promises that the badge reflects every rider's experience.The feed reflects MTA's editorial choices about which disruptions to publish. Riders sometimes experience delays that don't make it into the feed — a 4-minute hold at a single station, a temporary medical emergency that clears in 15 minutes, an unusually crowded train that dwells longer than scheduled. The badge is what the MTA system says, not a ground-truth measurement of every train's actual on-time performance.
Caching, fallback, and the failure modes you should know about
We cache the parsed feed in Vercel KV with a 60-second TTL. The page server-renders the initial badges from cache (which is what search engines and AdSense crawlers see), and a small client component polls every 60 seconds to refresh the grid in-place.
If the upstream feed call fails, we serve the last good cached payload for up to 5 minutes, with a small "last updated" timestamp at the top of the page so you can see the staleness. Beyond 5 minutes, we stop serving "everything is fine" data and show a page-level "Service status temporarily unavailable" banner. This deliberate fail-visible design exists because the worst possible answer for a transit-status tool is silently showing green badges while a major incident is in progress — riders make trip-planning decisions on this, and we'd rather show "we don't know" than guess wrong.
Per-line history and reliability
We track per-route delay observations in a rolling 30-weekday window and surface the result on each line's page (e.g., "the F has been delayed on 14 of the last 30 observed weekdays"). The history is recorded via a combination of organic-fetch piggybacks (every time someone hits the page) and a daily Vercel Cron at 6-7 p.m. NYC time, guaranteeing at least one observation per day even on low-traffic dates.
The reliability badge takes 15 weekdays of data to start surfacing — below that, the line's page shows "Tracking reliability since {date}" instead of a misleading partial count. After three calendar weeks of deployment, the full 30-weekday window is available. A few caveats:
We only count a day as "delayed" if MTA published a "Delays" or "Severe Delays" alert specifically. Suspended days don't count as delayed (they're a different operational state). Service changes and station notices don't count as delayed either. The result: the percentages skew lower than the "feels like the F is always screwed" vibe most commuters have, but reflect the tight, defensible operational definition.
If you want the deep technical details
The subway methodology page documents the MTA endpoints we read, the verbatim Service Status Box algorithm, the alert_type → status mapping table (including how we handle MTA introducing new editorial strings without warning), and the cache and failover behavior. The G train guide covers the structural reasons one specific line underperforms — which is the kind of context a status badge alone can't give you.
Common questions
How current is this data?
We fetch MTA's official subway service alerts feed every 60 seconds, and the grid on this page refreshes itself automatically while it's open in your browser. MTA itself publishes alerts within minutes of an incident being identified by control-center staff — so allow for a small lag between something actually happening on the tracks and it showing up here. The 'last refresh' timestamp at the top tells you exactly when the underlying data was retrieved. If we ever lose the feed entirely, the page shows an explicit 'temporarily unavailable' banner rather than a misleading all-green grid.
What does "Good service" actually mean?
Honest answer: it means there are no active alerts for the line, not that every train is running on time. MTA reserves alerts for material disruptions — a 2-minute delay on a single train, or one slow-zone segment, doesn't qualify. Quoting MTA's own developer note on the Service Status Box: "There can be minor service disruptions that don't have alerts associated with them." If you're standing on a platform watching the countdown clock tick up while this page says good service, that's the gap MTA's note is talking about.
Why does my line say "Delays" with no detail?
MTA sometimes posts a high-level alert status before the description text catches up — typically in the first few minutes of an incident, when control center is still figuring out the scope. Click the line in the grid to see all active alerts; there's usually more context once a few minutes have passed. If the description never fills in, that's MTA's own data, not a bug on our end. We surface exactly what their feed gives us.
What's the difference between "Service Change" and "Delays"?
Service change means trains are running differently than usual — rerouted onto a different line, skipping stops, running on the opposite-direction track, or short-turning before their normal terminal. Delays means trains are running slower or less frequently on the normal route. The two can overlap: a signal problem might cause both a reroute and a slowdown, in which case you'll see whichever alert MTA ranks more severely. If it matters which is which, click the line and read the description text.
Does this include weekend service changes?
Yes, but only the ones that are currently active. MTA publishes planned weekend changes in their Weekender newsletter and on their alerts feed with a future start time. Once that start time arrives, the change shows up here. We deliberately don't surface pre-announced future changes that haven't started yet — most people checking this page want to know what's happening right now, not what's scheduled for Saturday at 9:45 PM. For the full weekend planner, check new.mta.info/weekender.
Why don't you show countdown clocks (next-train arrival times)?
Honest scope answer: arrival times are a different product. They require parsing the per-line trip-update feeds (seven separate protobuf streams, each ~1-2 MB), joining them to the static station catalog, and updating every 30 seconds per station the user cares about. It's solvable but it's a lot of work for something MyMTA, Transit App, and Citymapper already do well. We focus on the system-wide 'is it running OK right now?' question because that's the cheapest, most-checked decision a New Yorker actually makes before leaving the apartment.
What if my line shows good service but I'm experiencing delays?
Two possibilities. One: the delay is small enough that MTA hasn't issued an alert yet — see the 'what does good service mean' answer above. Two: there's a real disruption and our feed hasn't picked up the new alert yet, which can happen if MTA's feed has a brief outage or if the alert was just created. Confirm with new.mta.info/alerts or the station countdown clock. If it's clearly a major issue and we haven't caught it within a few minutes, email hello@supernyc.com — we'll look at the feed and figure out what went wrong.
Is this affiliated with the MTA?
No. SuperNYC pulls public data from MTA's developer feeds and displays it in a more readable format. We're not endorsed by, affiliated with, or sponsored by the MTA. The route bullets, line names, and alert text all belong to the MTA — we just consume the open data they publish. For the official MTA experience, see new.mta.info or the MyMTA app.
What about buses, LIRR, Metro-North?
Out of scope for v1. We focus on subway because it's what most New Yorkers check most often — bus and commuter-rail status are useful but the audience is smaller, and the alert feeds are structurally different enough that they'd need their own page. If there's demand we could add bus alerts as a v2; LIRR and Metro-North are likely to stay on MTA's own properties since the riders for those services already have well-established habits there.
How is "Delays" different on the L train vs. the A train?
It isn't, structurally. Both lines use the same alert generation process — an MTA control center supervisor identifies a disruption, picks the appropriate alert type, and the feed publishes it. The L line has historically been more reliable thanks to its CBTC signaling (the modernized signal system that lets trains run closer together), but a 'Delays' alert on the L means the same thing as on the A: trains running slower than scheduled on the regular route. The reliability difference shows up in how often each line gets a Delays alert, not in what the alert means.