TransitRadar

How the daily figures are measured

The daily archive pages report what ran, what was cancelled and how late it arrived. This page explains how each of those is counted, and where the counting stops being exact.

What counts as a service

Every figure on a day page is counted from services recorded as settled — arrived, or cancelled, or more than two hours past their booked arrival. Passenger services only; freight is excluded throughout, and about 13% of the trains on the live map are freight workings that the passenger feed does not describe at all.

A day is only published once it is complete. A day still in progress is a running total: at midday the archive holds roughly a third of that day's trains, and a page built from it would report that third as the day's traffic — plausible-looking, and wrong. Dates carrying fewer than a thousand recorded runs are not published either, which filters partial capture rather than quiet days.

How punctuality is measured, and against what

Delay is measured at the destination rather than at intermediate timing points. That is a stricter test than the industry's own public measure, so these figures read a little worse than the published ones and are not directly comparable with them. The same caveat applies to the bus punctuality league, where roughly a quarter of buses arrive early because timetables pad the final leg.

The three punctuality bands are exclusive: within five minutes, five to thirty, and more than thirty. A train appears in exactly one of them.

Every percentage is calculated against the trains whose arrival was actually recorded, never against the number that ran. Those are different numbers, and on some dates they are very different. A service can be recorded as having happened with nothing captured about when it arrived; it counts toward the day's traffic and toward no band. Dividing on-time arrivals by total runs would have published "0.9% of trains arrived within five minutes" about an ordinary Wednesday — which is why each day page states its own coverage figure beside the bands.

Where fewer than half of a day's arrivals were captured, no punctuality figure is published at all. The page leads instead on what ran and what was cancelled, which are recorded in full. That is not a hypothetical safeguard: the archive's first ten days all fall below the threshold and always will, because nothing back-fills.

Cancellations, and why there are two on-time figures

A cancelled train has no arrival time, so it cannot sit in any punctuality band — every band in the archive is counted from services that were not cancelled. Left there, that quietly rewards cancelling: a train removed from the timetable disappears from the denominator instead of counting against the operator that removed it. The tables therefore carry two figures side by side, and they are the same on-time count over two different denominators.

“On time” is of the arrivals actually recorded — when a train ran, did it get there on time. “Incl. cancelled” adds the cancellations to that denominator, counting each as a failure the way the industry's own public performance measure does — was a booked train there, and on time. The two are exact rather than estimated: a run either was or was not cancelled, and a cancellation can never also appear in a band, so the totals simply add.

The gap between them is not decoration. Across the archived window it runs from nothing at all, for operators that cancel nothing, to more than eight points — and it falls hardest on exactly the operators that cancel most, which is the reason both are published rather than one. An operator can be among the most punctual on the network by the first measure and mid-table by the second, on the same data, in the same window.

Only the first is used for ranking, and for the filled bars on the day-by-day strip. That is a deliberate limit rather than a preference: the ranking compares operators on the sample of their running we actually measured, and its threshold is a number of recorded arrivals. Where the two figures disagree about an operator, both are on its page.

Why coverage varies between dates

The archive began on 5 August 2026, and its earliest dates are badly covered for a reason worth stating plainly. The forecast feed's tracker rebuilds itself from a timetable snapshot whenever the service restarts — booked schedules carrying no actual times — and the archive sweep used to write those straight over rows that already held real arrivals. Every deploy therefore erased part of that day's record. One such restart took a single date from 4,833 recorded arrivals down to 1,893.

That is fixed: a capture with no arrival time can no longer replace one that has it. Dates from 15 August 2026 onward carry proper coverage and state a punctuality figure. Earlier dates keep their gaps permanently, and their pages say so rather than reporting a figure drawn from a sliver.

Why the reasons are reproduced word for word

Cancellation and delay reasons are the operators' own words. Darwin publishes a reason as a complete sentence written for passengers — "This service has been delayed by a speed restriction" — so each is reproduced exactly as it arrived. Nothing is shortened, categorised, re-worded or prefixed, because a paraphrase would be this site putting words in an operator's mouth.

Cancellation reasons are the most reliable thing on these pages: even the worst-captured dates carry a reason for 78-100% of cancellations. A run cancelled part-way along, though, often carries no service-level reason at all, so the reason counts cover fewer trains than the cancellation total.

How the tables are ordered, and what that hides

The operator table is ordered by how many trains each operator ran, not by how well it did. A small operator with a handful of services can top or bottom a percentage table on a couple of runs, so ranking by performance would manufacture a league out of noise. Where coverage differs between operators on the same date, those with thin coverage are being judged on a smaller sample than those beside them — the runs and cancelled columns are complete regardless.

The longest-delay table lists individual services that arrived furthest behind schedule. A very long delay usually means the train was held behind something — an incident, a failed train ahead, a closed line — rather than that it ran slowly.

Comparing one operator with another

The per-operator pages report the same window as the daily ones, and three things about them are worth stating once here rather than on every page.

The on-time share and the average delay are different measurements and do not always agree. The share counts how many trains beat five minutes; the average counts how far the rest fell behind. An operator that is rarely late but badly late when it happens can sit above another on one measure and below it on the other, and neither number is the wrong one.

A ranking by punctuality takes no account of what each operator was asked to run. A long-distance operator crossing four regions accumulates delay from every one of them and has the fewest chances to recover; a self-contained suburban operator on dedicated track has neither problem. The gap between them is partly a description of the routes rather than of the operators, which is why both operator tables — the one on this index and the by-operator table on each daily page — arrive ordered by volume rather than as a league. Any column heading re-sorts them, including both on-time measures, but that is a view the reader chooses and the caveat above applies to whichever ordering they pick.

A punctuality sort will not place an operator it measured too little of. Such rows are listed last rather than ranked, which is the same judgement that withholds a figure from them in the first place. The threshold differs with the window: the operator index needs 500 recorded arrivals across the whole archive, and a single day needs 20 — a day being a far smaller sample. That floor is not decoration. Across the archive, 279 operator-days carry fewer than 20 recorded arrivals and 78 of them are a perfect 100%, so without it a handful of operators running a dozen trains would head the punctuality sort of nearly every daily page, above operators that ran thousands. Their figures are still shown; only their placing is withheld.

Cancellations have no coverage gap behind them, and punctuality does. Every run either was or was not cancelled, so a cancellation rate is complete even on dates and for operators whose arrival times were poorly captured. Coverage varies by operator as well as by date — where fewer than half of an operator's completed runs carry an arrival time, its page publishes no punctuality figure at all, the same threshold the daily pages use.

The longest-delay list on an operator's page is drawn from each day's national top ten, so it records that operator's appearances in the daily league and not its own worst delays. A delay shorter than another operator's tenth-worst on the same date does not appear. Many operators never appear at all, which is itself the useful figure.

The bus figures, and why they sit on the same page

Bus punctuality is measured the same way and carries the same warning, more strongly: these are our figures, not the regulator's, and they are not comparable with an operator's published performance. We judge a journey once, at arrival at its destination, while the regulated measure counts departures from timing points along the route. Coverage is a set of larger urban areas rather than the whole country, and journeys that cannot be matched confidently to a scheduled trip are discarded rather than guessed at. Why buses run early explains the whole picture — roughly a quarter of buses arrive ahead of time, which is a timetabling artefact rather than good performance.

A bus service day runs from 02:00 to 02:00, while a train's date is its schedule's own start date. The two windows are close but not identical, so a late-night journey can sit either side of the boundary depending on which network it belongs to.

Bus punctuality was archived later than the vehicle counts, and the gap is visible on the older day pages. The daily tally used to be discarded when the service day rolled over, so for dates before it was kept, nothing can be recovered — those pages show vehicle activity and no punctuality. Where a day page omits the bus section entirely, it means the archive was not recording buses at all on that date, which is a different statement from "no buses ran".

Where the data comes from

Built from this site's own archive of settled services, assembled from the National Rail Darwin Push Port forecast feed and Network Rail TRUST movement messages. The feeds themselves retain about 30 hours, so anything older than that is only here because it was captured as it happened — these pages are not a query against someone else's history.

Allocation data, where a day page reports it, comes from the Rail Data Marketplace and says which units an operator allocated to a service. It is not an observation that they formed the train, explicitly not during disruption, and several operators publish nothing at all — so those figures are always "of trains we hold an allocation for", never of the day's traffic.

Where the data comes from lists every source and its licence; how it works explains how a delay is attributed to a train in the first place. The daily archive index lists every published date.