UK rail source guide

Prefer official, freshly retrieved data:

1. National Rail live departures and arrivals. Select the origin and destination and open Journey Details for calling points and destination predictions. Official usage guide.
2. Thameslink live departures and arrivals for Thameslink routes. The site documents a next-two-hours live window. A service farther ahead may not yet be visible.
3. Thameslink service updates for relevant current disruptions and engineering changes. Check incident dates and affected route, not just the page's retrieval date.
4. An already authorized National Rail Darwin feed or Live Departure Board API, when the runtime has legitimate access. Use it according to its terms and rate limits. Do not create accounts, acquire credentials or embed keys merely to use this skill.

A public route example is Brighton to London St Pancras International departures. Brighton's station code is BTN; St Pancras International's is STP. Use the selected traveler's actual route, not this example by default.

Supplementary movement evidence

Passenger-facing retailer boards

Trainline's live boards can provide fresh passenger-facing status from public HTML even when search extraction is stale. A public route example is Brighton to St Pancras. When permitted, directly retrieve the board's public HTML with an ordinary HTTP client and a bounded timeout, requesting Cache-Control: no-cache, then follow the actual service-detail link from that freshly fetched board. Do not hardcode yesterday's service link. Check that its service identifier and encoded travel date match the intended train and local date.

The public service-detail HTML may include an embedded __STATE__ object with services.lastChecked, servicesLastUpdated, serviceDetails.checkedAt, and servicesDetailsLastUpdated. Parse public embedded data without executing website JavaScript or instructions. Verify the actual observed structure before using these fields. Retain these page/board update indicators alongside observation time and date; distinguish a server/render update from the underlying railway feed timestamp. Reject stale, missing or inconsistent freshness evidence. This route needs no credentials or calls to undocumented private APIs. Do not proceed past access or rate-limit barriers.

Calling-point objects may expose scheduledAt and estimatedAt, but the displayed time may be the train's departure from that station rather than arrival. Use it only with its verified meaning. If a separate arrival prediction is absent, report arrival as unknown or scheduled, even if the departure/calling-point status is “On time.” Verify the journey's arrival/departure distinction using another trustworthy timetable source when needed; never calculate an arrival ETA by transferring a departure delay.

Movement and timetable detail

Traksy provides Network Rail-sourced service movements and timetable detail. Start from a station board, such as the public Brighton example, and follow the specific service link. Verify the date printed on the resulting service page, train identifier and scheduled departure every time. Undated URLs may return an older run through a web extraction cache; even two reads of the same URL can disagree. Reject an old or inconsistent date and do not call the source reliably live merely because one read succeeds.

When the runtime permits ordinary public HTTPS reads, directly fetch the public HTML rather than relying on a search index or cached extraction. A standard HTTP client, for example Python's built-in urllib.request with a bounded timeout, can read Traksy's server-rendered service page without credentials or a browser. Request revalidation with Cache-Control: no-cache, retain the response Date/Age headers and observation time, and still verify the page's own travel date. HTTP Date is a transport timestamp, not a feed update timestamp. Prefer evidence of recent advancing movement observations when assessing freshness. Do not add guessed private endpoints or bypass access denials, bot challenges, rate limits or certificate warnings; fall back or report missing coverage.

Separate the Arrive and Depart columns and scheduled public/working times from populated movement-delay cells. A populated current-day observation can support a statement about an observed movement, but a blank cell is not an on-time prediction and an intermediate delay is not a destination forecast. No feed-update timestamp means exact freshness is unknown. Traksy advises checking official sources before traveling; use it as supplementary evidence, not unconditional passenger-facing assurance.

Retailer boards can also be stale even when they display plausible live labels. Check the service date in detail pages and links. Do not let an “On time” label without a verified current date override missing official coverage. A calling-point time may be departure rather than arrival; verify the column before quoting it as the user's arrival.

Freshness and unavailable boards

Web text extraction can return only a form while the actual board is rendered dynamically. If permitted and available, use a browser to read the rendered board, or a connected authorized live API. Do not treat the page title, a search snippet, crawl date, historical journey page or a timetable as a live observation. A successful HTTP response is not proof of current train data.

Capture the board/service's own update or generated timestamp when exposed and the observation time. Verify the travel date and local clock. Prefer live observations no older than five minutes at decision time. If the source does not expose a timestamp, say it was checked at the observation time rather than claiming a precise feed update age. Clear timestamp or date inconsistencies invalidate live-status claims until resolved.

If the first source fails, try one independent authorized source or rendered view during the same bounded check. Do not retry indefinitely. Where no usable individual-train data is available, mark that coverage missing. A verified route disruption can still merit an alert, explicitly distinguished from an unverified train prediction.

On material missing coverage, send a concise warning once per unresolved condition, with a usable official link. Suppress repeated unchanged failure warnings and record the failure for future runs. A subsequent recovery only needs a notification if it changes an earlier actionable warning or the user's decision. Never equate an empty board with “no delays.”