Switzerland Rail Service Tracker
Check Swiss station departures or arrivals with public timetable data and follow platform, delay, and route-stop changes for one service.{{ summaryTitle }}
{{ summaryLine }}
Route visual unavailable.
| Service | Destination | {{ board_type === 'arrivals' ? 'Arrives' : 'Departs' }} | Expected | Platform | Delay | Track | Copy |
|---|---|---|---|---|---|---|---|
| No services matched the current board and filters. | |||||||
| {{ row.service }}{{ row.operator }} | {{ row.destination }} | {{ row.planned }} | {{ row.expected }} | {{ row.platform }} | {{ row.delay }} | ||
| Stop | Arrives | Departs | Platform | Delay | Copy |
|---|---|---|---|---|---|
| The selected service did not return route-stop checkpoints. | |||||
| {{ row.stop }}{{ row.status }} | {{ row.arrival }} | {{ row.departure }} | {{ row.platform }} | {{ row.delay }} | |
Travel notes
- {{ item.title }}{{ item.detail }}
This is a transient public-data snapshot. Confirm platforms, cancellations, and connection decisions with station displays or the operator.
A station board answers a checkpoint question: what is expected to depart from or arrive at one stop near a chosen time? It is narrower than a journey planner. The board may show the next service and its current platform, but it does not prove that a connection will be held, that a ticket is valid, or that disruption instructions have not changed.
Swiss public transport data combines timetable times with prognosis fields. A planned time comes from the timetable; an expected time reflects the latest returned forecast when one exists. Platforms and delay values can change after the snapshot is fetched, so the observation time belongs with any pickup, boarding, or connection decision.
| Board value | Meaning | Useful caution |
|---|---|---|
| Planned | Timetabled arrival or departure at the checkpoint | It does not change when a prognosis becomes late or early |
| Expected | Latest returned prognosis, or the planned value when no prognosis is available | It can be absent or revised after the request |
| Delay | Provider delay or the rounded difference between expected and planned time | One checkpoint does not predict every later stop |
| Platform | Returned platform for the selected checkpoint | Station displays remain the operational reference |
Departure and arrival boards use different checkpoints. A traveler catching a train normally needs departures, while someone meeting a passenger often needs arrivals. Service numbers and advertised destinations help separate similar rows, especially at large stations where several operators or transport modes may appear together.
Delay can also change along a route. A service may leave six minutes late and recover time later, or it may accumulate delay after the selected station. Route-stop forecasts are evidence of the returned path, not a guarantee of future running. Refresh close to the decision and confirm important changes with the operator or station display.
How to Use This Tool:
Choose the station and the direction of travel before narrowing the returned board.
- Enter an official or familiar Swiss stop name in Station, then select Departures or Arrivals. Leave Rail services only on for trains; turn it off when tram, bus, ship, or cableway rows are also relevant.
- Select Fetch live board for current public data, or load the fixed example only to learn the workflow. If no station matches, shorten the query to the main stop name.
- Use Destination contains, Service contains, Future window, and Displayed rows only when the live board is too broad. These controls filter the returned snapshot rather than creating a new journey plan.
- Choose Track on the correct service row. Confirm its expected time and platform, then inspect Route stops or Delay path when later checkpoints matter.
Interpreting Results:
The selected row is the first matching service unless another row is chosen. Confirm the service number, advertised destination, route, and board direction before treating its platform or delay as your trip.
- On time means the returned delay is exactly zero minutes. It does not guarantee an unchanged departure.
- A positive value up to 5 minutes is shown as a small delay; a value above 5 minutes is shown as a delay. A negative value is an earlier prognosis.
- Cancelled takes precedence over the numeric delay label.
- The route chart shows returned checkpoint forecasts. Recheck the current board before changing platforms, relying on a connection, or coordinating a pickup.
Technical Details:
A live request first resolves the entered stop to one station record, then requests a bounded station board for that station, direction, time anchor, and transport scope. Returned journey and checkpoint fields are normalized into a board, one selected route, and a delay series.
Lookup Core
Station matching removes common words such as “station,” “Bahnhof,” and “Hauptbahnhof” from the comparison text. An exact normalized station name wins; otherwise the first name containing the query wins, followed by the provider's first usable match.
| Step | Rule |
|---|---|
| Provider request | Request departures or arrivals for the resolved station, up to 40 rows, using Swiss local date and time. |
| Transport scope | Train only, or train plus tram, bus, ship, and cableway. |
| Text filters | Destination and service comparisons are case-insensitive substring matches. |
| Future window | When selected, keep rows from 30 minutes before the anchor through the inclusive future limit of 60, 120, 240, or 360 minutes. |
| Order and cap | Sort by the best expected-or-planned timestamp, then keep the selected local limit or at most 40 rows. |
Formula Core
A numeric provider delay is used first and rounded to the nearest whole minute. When it is missing, delay is derived from the expected and planned timestamps. The result is bounded to minus 1,440 through plus 1,440 minutes.
If either timestamp is unavailable and the provider supplied no delay, the normalized delay is 0. For that reason, the presence of an expected time matters when distinguishing an explicit on-time prognosis from missing forecast data.
Rule Core
| Condition | Label |
|---|---|
| Cancellation flag is true | Cancelled |
| Δt = 0 minutes | On time |
| 0 < Δt ≤ 5 minutes | Small delay reported |
| Δt > 5 minutes | Delay reported |
| Δt < 0 minutes | Earlier prognosis |
The Board anchor can move the request from 1 hour earlier to 12 hours later. All anchor values are formatted in the Europe/Zurich time zone, including daylight-saving changes. Auto-refresh repeats the live request every 15 to 300 seconds only while a live board is loaded and refresh remains enabled.
Accuracy and Privacy Notes:
The public timetable service receives the station search, board direction, request time, and transport scope. Destination, service, future-window, and display-limit refinements are applied to the returned rows in the browser.
- Forecast times, platforms, cancellations, and route-stop coverage can be absent, late, or revised after retrieval.
- Auto-refresh creates repeated provider requests. Use it only while actively monitoring a board and stop it when the snapshot is no longer needed.
- A station-board row does not establish connection protection, replacement transport, ticket rights, or disruption instructions.
- The fixed example is dated demonstration data and must not be used for travel.
Worked Examples:
Delay recovery after Zürich
In the fixed example, S 11 leaves Zürich HB with a 6-minute delay, reaches Zürich Oerlikon at 6 minutes late, Winterthur at 5 minutes late, and Seuzach at 4 minutes late. The falling line shows recovery in that saved snapshot, but it does not promise that the live service will follow the same path.
References:
- Swiss public transport API documentation, transport.opendata.ch.
- Real-time and forecast data overview, Open data platform mobility Switzerland.