The TTC stations with the highest delay intensity aren't the busiest ones

Our previous piece on subway delays worked entirely from the raw delay-record file: which categories cause the most delay time, which line carries the biggest share, when disorderly-patron incidents actually happen. In the "what would update the chart" section we named the gap directly: per-station usage data to weigh raw counts against, which does not ship in the open-data release. Without it, every station-level count is really just a proxy for station size — big interchange hubs top every list by construction, because more trains and more platform activity mean more opportunities for a record to be logged.

We went and got it. TTC's own Subway Ridership 2023-2024 report publishes typical-weekday station usage for every station — in TTC's words, "the number of customers travelling to and from each station platform on a typical weekday." That's a different figure from the line-level "boardings" total the same report also publishes (Line 1 as a whole: 625,467 boardings). We're using the station-specific usage figure, station by station, split by line where a station serves two lines. Joined against 2025's subway delay records, station by station, that turns a raw count into an adjusted delay intensity: records per 100,000 typical-weekday station uses.

The ranking flips when you adjust for station activity

Rank stations by raw 2025 record count and the list is the busiest stations on the network, in order: Kennedy, Bloor, Finch, Kipling, St George. That's mechanical — more platforms and more train movements mean more chances for a record to be logged, independent of whether the station is unusually delay-prone relative to its own size.

Rank the same stations by delay intensity — records per unit of station activity, not records per station — and eight of those twenty barely survive: Broadview, Davisville, Keele, Kennedy, Vaughan Metropolitan Centre, Warden, Wellesley and Wilson are the only stations that appear in both top twenties. The other twelve spots in the adjusted top twenty are filled by stations that don't crack the raw top twenty at all — led by Rosedale, Donlands, Summerhill and Leslie, four names that appear nowhere near the top of a raw-count ranking.

St George, one of the busiest stations in the system (209,994 typical-weekday station uses, reported by TTC as 101,128 on Line 1 and 108,866 on Line 2, combined here into one physical station), has the lowest delay intensity on the entire map: 326 records per 100,000 station uses. Rosedale, a small Line 1 station between Summerhill and Bloor-Yonge with under 5,000 typical-weekday station uses, tops the list at just over 5,000 per 100,000 — roughly fifteen times higher.

Don't read this as a precise league table

Rosedale has the highest observed delay intensity in the network. That's a different claim from saying Rosedale is definitively worse than Donlands, its closest rival. Rosedale's 245 records and Donlands' 301 records both carry real sampling uncertainty — using a standard 95% interval around each count, Rosedale's plausible range is roughly 4,400 to 5,660 per 100,000, and Donlands' is roughly 4,230 to 5,300. Those ranges overlap substantially. The honest claim is that Rosedale has the highest measured rate this year, not that it's been shown to be worse than its nearest neighbour.

That uncertainty widens for every station further down the list, because it's a function of how few records each station logs. That's not a flaw in adjusting for station activity — the adjustment itself is doing exactly what it should. It's a real limitation of ranking on small counts: when both the numerator and the denominator are small, a handful of additional records can move a station's position substantially. Treat the top few positions as a real, if imprecise, signal, and treat exact rank order in the bottom half of the table as much softer.

What "delay intensity" actually measures

This isn't passenger-minutes lost, and it isn't the odds that any individual rider hits a delay. Station usage counts people travelling to and from each station platform; it doesn't tell us whether a given delay record affected someone passing through that station on that particular train. So the fairer description of what's plotted here is: how often a delay record gets logged at a station, relative to how much activity passes through it — not how many people it affects.

Four stations in TTC's ridership report serve two subway lines and so get two separate usage figures, listed twice: St George, Bloor-Yonge, Spadina and Sheppard-Yonge. We combine three of them into a single row using their two-line total, because the underlying delay log doesn't distinguish the two platforms by name. St George reports 101,128 (Line 1) and 108,866 (Line 2), which we sum to 209,994 for the "busiest station, lowest intensity" comparison above; Spadina and Sheppard-Yonge are combined the same way. Bloor-Yonge is the exception: the delay log records its two platforms under genuinely separate names, "Bloor" and "Yonge," so we've kept it as two rows here too, matching TTC's own 121,531 (Line 2/Bloor-Danforth) and 156,643 (Line 1/Yonge-University) figures.

What gets counted

We counted every 2025 record we could match to one of the 71 stations in this analysis, across 129 distinct TTC delay codes that actually appear in the 2025 data — door faults, signal problems, disorderly patrons, weather, mechanical failures, medical aid, and the rest. About 90% of 2025 subway delay records match to a specific station this way; the rest are logged against non-station locations — yards, line segments, control divisions — that don't correspond to a single platform and are excluded from station totals. Unlike our previous article, which worked from delay-minute totals, this analysis counts every logged record regardless of duration: about 65% of 2025 subway delay records carry zero recorded delay minutes. TTC's delay-monitoring system logs these events whether or not they produced a measurable delay, so a station's count here reflects logged-event frequency, not lost time. That's a genuinely different thing from the previous article's hours-lost analysis, and the two aren't meant to be compared number-for-number.

About 9% of those records (2,378 of 25,737 in 2025) use TTC codes without a corresponding public description in the current codebook. We include them in the station totals rather than dropping them; they aren't assigned to a specific cause in this analysis, and we haven't broken them out by station.

Data and methodology

• Delay records: City of Toronto Open Data, TTC Subway Delay Data, calendar year 2025, all stations, all 129 codes that appear in the year's data, no filtering by delay duration.
• Station usage: TTC Subway Ridership 2023-2024, a typical-weekday station-usage figure (in TTC's words, customers travelling to and from each station platform) covering September 2023 through August 2024 — a different metric from the line-level "boardings" total the same report publishes. This is not the same year as the delay-record count; there's roughly a one-year gap between the two periods, carried forward rather than implied as same-year. TTC station-level usage doesn't move fast year to year, but treat the intensity figure as approximate for exactly this reason.
• Delay intensity: 2025 delay records ÷ typical-weekday station usage × 100,000, i.e. "2025 delay records per 100,000 typical-weekday station uses." This is an annual intensity measure, not a literal daily rate — the numerator spans a full year, the denominator is a single typical day.
• Uncertainty: approximate 95% intervals use a normal approximation to the Poisson count in each station's numerator, holding the denominator fixed.
• Station count: 71 rows, covering all 70 TTC subway stations (TTC's own published count as of November 2023). One row, Bloor-Yonge, represents two platforms because the delay log names them separately (Bloor, Yonge). TTC's report lists four stations as serving two subway lines (Bloor-Yonge, St George, Spadina, Sheppard-Yonge); the other three are combined into a single row here using their two-line usage total, since the delay log doesn't distinguish their platforms by name.