Live train delay feed integration: which feeds carry delay data, and how they land in your stack

Delay never arrives as one tidy dataset - it is a field inside each operator's real-time service record. The National Rail Data Portal (UK) publishes Darwin, the live departure-board prediction system: one record per train per station call, carrying due, expected and actual times alongside platform and cancellation flags, plus network-wide incident messages. Darwin describes roughly tens of thousands of daily Great Britain train movements across every operator, covering the current day plus the forward schedule.

Rows before architecture - the shape decides what your alerting logic can express:

# GB delay record (Darwin family) - one row per train per station call
train_id     : <operating service identity>
loc_stanox   : <timing-point location code>
planned_dep  : 08:42   forecast_dep : 08:51   actual_dep : 08:53
delay_min    : +9       cancel_flag : N        platform   : 4
cif_train_uid: <schedule identity the delta resolves against>

# realised journey (Swiss actual data v2) - one row per stop pass
journey_id   : <operating day run identity>
stop_id      : <UIC / SUISA stop identifier>
planned_arr  : 09:14   realised_arr : 09:22   diff_min : +8
planned_dep  : 09:16   realised_dep : 09:24   diff_min : +8

# deviation (German timetable) - same trip after reality intervened
eva_number   : <station EVA number>   date : <service date>   hour : <service hour>
trip         : <line or train designation>   planned vs recorded : <per-call delta>

Read what the columns imply before reading what they promise. A prediction and an actual are different facts with different shelf lives - boards consume forecasts, punctuality panels consume outcomes, and conflating them is how "on time" claims fall apart under audit. Every record above joins back to its scheduled counterpart on stable identifiers: CIF train UID in Britain, journey and stop identifiers in Switzerland, EVA number plus date-hour in Germany. That join - not the lateness minute itself - is the part worth engineering once; Datadory ships it resolved so the delta arrives attached to the plan rather than floating free.

Two asymmetries matter more than the format differences. First, grain: Britain reports at the timing point across all operators, while Germany's timetable products key on station-date-hour, so a corridor question needs different joins per country. Second, memory: only the Swiss platform archives its own history deliberately - 117 twice-weekly snapshots preserving Timetable 2026 (14 December 2025 to 12 December 2026) - whereas the others serve the moving present and leave the past to whoever kept it. If your product ever has to explain what a board showed last Tuesday, plan the archive side from day one.

Beyond the four national operators, the Transitland Open Transit Feed Registry indexes thousands of registered GTFS, GTFS Realtime, GBFS and MDS feeds worldwide - Amtrak and commuter rail included - each with a permanent Onestop ID and versions deduplicated by content hash since registration, which makes it the discovery layer when your coverage question spans operators rather than countries.

A minute count alone rarely explains anything. Three auxiliary layers convert raw lateness into something a rider, an operations desk or an investor can act on.

Facility state. Deutsche Bahn's FaSta product reports the operational state of public elevators and escalators across roughly 5,400 stations referenced by the station master data - the difference between "your train is late" and "the lift is out at your interchange," which is a different passenger message entirely.

Incident attribution. Darwin carries network-wide incident messages beside the departure predictions, and the Swiss platform publishes network-wide alerts, so a cluster of late services resolves to a named disruption instead of being reverse-engineered from timestamps.

Historical baselines. Whether today's eight minutes is normal depends on what normal is. The ORR Data Portal carries nine themes of accredited GB statistics led by 447 million quarterly passenger journeys with punctuality tables reaching back to 2011; the FRA accident series inside the Data.gov US Rail Catalog reaches to 1975; ERA's Common Safety Indicators span 347 indicator codes from 2006 to 2024. None predicts tomorrow - all three tell you what the long-run operating environment looks like, which is the denominator any SLA or reliability claim needs.

Four integrations pay for themselves fastest, and all four consume the same underlying rows.

Departure boards and journey planners. Per-train predictions scoped to served stations are the raw material of every "next train" screen. Pair the live layer with SNCF's 151-day rolling timetable and the Swiss snapshot archive and the planner answers questions two quarters out as confidently as two minutes ahead.

Disruption alerting. Incidents joined to affected services turn a wall of lateness into routed notifications: which trains, which stations, which alternative. This is the workflow where facility status earns its keep, because "step-free entrance unavailable" reroutes someone in a way a delay badge cannot.

Plan-versus-actual performance analytics. Joining schedule to outcome, with the historical baseline underneath, separates measured delay from guessed delay - the difference between an operator benchmark that survives diligence and one that does not. The ORR tables supply the accredited external check.

Reliability clauses and market studies. Punctuality distributions anchored on published statistics give contracts, tenders and corridor investments an evidentiary floor instead of anecdote. The persona-ranked shortlist lives on our rail transportation data for developers builders page.

Datadory normalizes before delivery: the delta arrives pre-joined to its scheduled entry, station and journey identities resolve against the reference layer, incidents ship as dated scoped events rather than free text, and the historical baselines load beside the live stream under one field dictionary. When an operator changes something upstream, it surfaces as new rows under the same schema - a settings conversation, not a re-integration project.

Name the networks, stations and grains when you request a sample: a departure-board team gets Darwin calls for its served stations, an analytics group gets plan-versus-actual keyed on the schedule spine, and both see real rows before any commitment.

Start with the dataset pages behind the four feeds - National Rail Data Portal (UK), SNCF Open Data Portal, Open Transport Data Switzerland and DB Open Data and DB Developer Portal - each with the full field dictionary, sample rows and coverage chips. For the definition underneath the live layer, read the glossary entries for GTFS Realtime; for the whole 17-record landscape this article draws from, the rail transportation data guide scores every source, and the rail-transportation data hub keeps the dataset pages, lists and persona guides one click away.