How a delay is measured, and why every source disagrees

Ask three rail data feeds how late a train was and you will get three answers, all honest. They are measuring different things, at different moments, for different reasons.

“Ten minutes late” sounds like a fact. It is actually the answer to a question with at least four hidden parameters: late against what, measured where, at which moment, and counted how. Change any one and the number changes.

Late against what

Every delay is a comparison against a booked time, and the railway has more than one.

The working timetable is the operational plan. It includes times at points with no platform, allowances deliberately built in for recovery, and — on 44% of all timing points in a typical extract — instructions to pass through without stopping. The public timetable is the subset a passenger is offered, and its times are frequently a little later than the working ones, because padding is added before the point where lateness gets measured.

A train can therefore be running late against its working timetable and exactly on time against the public one. Both statements are true. We compare against public times where they exist, because that is the promise made to the passenger.

Measured where

This is the parameter that causes the most confusion, and it is the reason our punctuality figures look worse than the ones the industry publishes.

The regulated measure counts performance at timing points along the route. We measure arrival at the destination. A train that loses eight minutes early on and claws back six through built-in recovery time counts as several small failures on the first measure and as a two-minute delay on ours.

Neither is a trick. Measuring at timing points tells an operator where its network is failing; measuring at the destination tells a passenger whether they got there when they were told they would. We do the second because this is a passenger-facing site. It does mean our figures are not directly comparable with an operator's published performance, and we say so wherever we show one.

At which moment

The three feeds behind this site report at different stages of a journey, which is why they disagree in real time.

TRUST — movements

Network Rail's movement feed reports a train arriving at, departing from or passing a location. Crucially, it carries no delay at all until the train has actually reported a movement. We once checked the live feed at 01:45 and found every single active entry was merely activated — the train existed in the system and had gone nowhere. Anything reading lateness from TRUST at that hour reads nothing.

Darwin — forecasts

National Rail's forecast feed publishes an expected time for each remaining stop, plus actual times once they happen. It is the only source of the plain-English reasons you see on our boards, and the only one that covers per-stop cancellations. It does not cover freight.

Our archive — outcomes

Once a run has finished we record what happened and keep it, because both feeds discard detail after roughly thirty hours. This is what the daily archive is built from, and it only ever contains settled runs: arrived, cancelled, or long past due.

A train mid-journey has a forecast delay that will change. A finished train has an outcome. Comparing a forecast against an outcome and calling the difference an error is the most common mistake made with this data.

Counted how

“On time” in Britain conventionally means within five minutes, and that is the threshold we use so our figures line up with the industry's own convention. Note what it hides: a train four minutes late and a train exactly on time are the same number.

Cancellations are counted separately and kept out of the delay average. A cancelled train has no lateness, and folding it in as zero would flatter every average on the site. It is also why you will sometimes see a day with a good average delay and a bad cancellation count: those are two different failures and averaging them together hides both.

The honest caveat: coverage

A delay figure needs a recorded arrival, and not every run produces one. Where a service settles without an arrival time ever reaching us, it counts as a train that ran and as no delay measurement at all.

That gap can be large, so every punctuality percentage on this site is calculated against the runs we actually measured, never against every run — and the number measured is shown beside it. Where coverage for a day is too thin to support a figure, the page says so and states no punctuality at all rather than dividing a small measured sample by a large total. That produces a page that admits what it does not know, which we would rather publish than a confident wrong number.

Which number answers your question

“Will I get there on time?” — the forecast on the departure board, which is Darwin's expected time and updates continuously.
“How late was it in the end?” — the outcome, on the service page for that run.
“Is this train usually late?” — the run history on the service page, which reads our archive rather than any live feed.
“How is the network doing right now?” — train punctuality, which is the industry's own live measure and is calculated by them, not by us.

Where this comes from

TRUST and the timetable are Network Rail open data; forecasts, actual times and reasons are National Rail's Darwin feed. Both are described with their licences on where the data comes from, and how it works covers the mechanics of the rest of the site.