About this service

Why it exists

Journey history shows what happened at the gates, but it does not automatically tell you how late a trip was, whether the applicable threshold was 15 or 30 minutes, or which claims you have already handled. The dashboard brings those questions into one place.

The service is designed for ordinary Tube, DLR, London Overground and Elizabeth line passengers. It combines an imported statement with expected route times and available disruption records, then presents the result as a suggestion to review rather than a definitive verdict.

How journey screening works

1. Read the journey record. The dashboard extracts the date, origin, destination, entry and exit times, fare and card label from a supported Oyster CSV or contactless PDF.
2. Identify the service. Where the statement is not explicit, the route is checked against TfL journey-planning data. A journey is held for review when the service cannot be established safely.
3. Estimate the expected time. Matching itineraries are selected for the route, service, date and departure time. A small station access and exit allowance is included because gate-to-gate records should not be compared directly with platform-only timings.
4. Compare actual and expected time. The difference becomes the calculated delay. The dashboard applies the relevant TfL threshold and your chosen screening sensitivity.
5. Look for supporting context. Available TfL line-status snapshots are matched by date, time and service. A match is useful context, but it cannot prove the exact cause of an individual journey delay.

Why estimates vary: interchanges, walking routes, temporary closures and the journey planner's available options can all change an expected time. The journey details screen shows the data used and lets you correct the service or journey record.

What the labels mean

Data and privacy choices

You can use the dashboard signed out. In that mode, imported journeys and results are stored in that browser. Creating an account enables private cloud sync, while paid plans can process only the TfL emails that you choose to forward. The service never asks for a TfL password and does not connect to your mailbox.

Expected-time requests use TfL's public APIs. Signed-in account data is hosted in a private AWS database and served over HTTPS. The full categories, purposes and retention periods are set out in the privacy notice.

Accuracy and maintenance

The application and guides are reviewed when TfL changes its published refund rules, journey data or statement formats. Import parsing and eligibility logic are covered by automated tests, and the public demo uses fictional journeys rather than a real passenger's records.

There will still be edge cases. If a route is wrong, edit the journey before claiming. If the official TfL guidance conflicts with this site, follow TfL's current guidance. Errors can be reported through the support link in the dashboard.

Independence and funding

This is a privately operated UK project and is not affiliated with or endorsed by Transport for London. TfL, Oyster and related marks belong to their respective owners.

The free plan may display clearly identified advertising after the site is approved and appropriate consent controls are active. Paid subscriptions support hosting and add automation; they do not buy a more favourable eligibility result. The same core journey-screening rules apply to everyone.