The TTC has now added 6 Finch to the collection of published delay data available on the City of Toronto’s Open Data site. See:
The data are in a summary format, much less detailed than the version on which I based a recent article, but they have the advantage of being in spreadsheet format that makes general analysis easier.
In the form published by the TTC, the data include:
- Date and time of the event
- Location
- Event Code
- Minutes of delay and gap
- Direction
- Vehicle number
- List of event codes
For the purpose of this article, I sorted and summarized the events by code and by the number of times it was reported. (If you want to see the full unedited list, download the file from the City’s site.)
What is immediately obvious here is that the majority of the delays are due to equipment and infrastructure failures, and that a few individual events caused extended outages. These are numbers as reported by the TTC, and do not really show the degree to which 6 Finch was effectively unavailable to riders who had to use shuttle buses instead.
Overall, in the period from December 7-31 there were 350 events.
Updated January 21, 2026 at 10:40pm:
By comparison, the streetcar network, with many longer routes in a more challenging operating environment, had only 819 events between them. Of these, 22 were infrastructure issues (with only 2 switch issues), 74 were due to equipment issues and 113 to diversions. Common incidents were due, broadly speaking, to passenger issues: 102 ill patrons, 106 unsanitary cars, and 169 security issues (most commonly “disorderly patron”).
| 501 Queen | 160 | 509 Harbourfront | 23 |
| 504 King | 166 | 510 Spadina | 75 |
| 505 Dundas | 124 | 511 Bathurst | 59 |
| 506 Carlton | 115 | 512 St. Clair | 69 |
| 507 Long Branch | 28 |
Steve Munro 
While the data is not enough detail, I do appreciate that this is one clear and simple way for the TTC to make clear where to direct one’s ire. If enough reports like this appear, it might break through into media reporting and adjust their framing too.
Steve: It will be interesting to see if TTC/City folks get into a fight with Metrolinx about the cost of all those shuttle buses. Remember that TTC is holding off on 2026 service improvements because they are keeping buses in reserve for Finch.
LikeLike
“Operator Overspeed” sounds like a job title they need.
I can’t believe there isn’t a configuration menu option to disable the automatic shutdown on overspeed, or at least set the overspeed threshold to something more speedy.
Hopefully the 6 “Injured TTC Employee” and 6 “Injured/Ill Customer” events are at least partially data entry errors. That’s a lot for a 3 week period… although I guess it includes a lot of holiday trips and a couple of universities/colleges so maybe some of those are self-inflicted.
Steve: From the detailed logs that I already had and reported, one injury was caused by a piece of equipment falling onto the operator, one by an op getting their finger caught in a washroom door, and I believe at leaset one other is from a fall caused by an emergency stop. Although they are reported here under one code, from the detailed logs those were ill customers.
LikeLike
Fire that Other guy. He’s responsible for a *lot*. In fact, by number of incidents, Other’s Equipment is the *worst*.
EQUIPMENT – OTHER
TRANSPORTATION OTHER
SECURITY OTHER
At least they keep stats. Do they use them to improve the system?
Steve: Equipment faults are not the TTC’s to fix. What Metrolinx’ partner, Mosaic does about reducing failures I don’t know because they do not report their actions publicly.
LikeLike
I can’t stand that term “partner” – “Mosaic” is a contractor (in addition to being a very old web-browser). There is a contract covering each party’s responsibilities. Gonna assume that said contract lets the supplier off the hook for most stuff. And that TTC gets no say at all.
What a dumb way to run a railroad.
Steve: I too find “partner” distasteful, but it is a common way the three entities refer to each other.
LikeLike