| # | Service | Destination | {{ boardLabel === 'Arrivals' ? 'Arrives' : 'Departs' }} | Expected | Platform | Delay | Copy |
|---|---|---|---|---|---|---|---|
| {{ idx + 1 }} |
{{ svc.name }}
{{ svc.operator }}
|
{{ svc.destination || '—' }}
{{ svc.directionText }}
|
{{ svc.plannedLabel }} | {{ svc.expectedLabel }} | {{ svc.platform || '—' }} | {{ svc.delayLabel }} |
|
| # | Stop | Arrives | Departs | Platform | Delay | Copy |
|---|---|---|---|---|---|---|
| {{ idx + 1 }} |
{{ stop.name }}
{{ stop.status }}
|
{{ stop.arrivalLabel }} | {{ stop.departureLabel }} | {{ stop.platform || '—' }} | {{ stop.delayLabel }} |
A rail station board is the short-horizon list of services expected to leave or reach a station next. That matters when platform choice, pickup timing, and connection margin can change within a few minutes. This tracker pulls the current Swiss board for a named station and turns it into a service list you can scan quickly.
It is most useful when you already know the station and need to answer a narrow question such as which departure is still viable, whether an arrival is drifting, or whether a platform is worth heading toward now. In a busy place such as Zurich HB, Bern, or Geneva Airport, the difference between a planned time and an expected time is often the piece of information that decides whether you walk, wait, or re-check the next service.
The board stays focused on station-side decisions rather than end-to-end journey planning. You get the service name, destination, planned time, expected time, platform when it is available, and a delay badge that makes late, early, and cancelled rows stand out. If you narrow the list by destination or line, the rows you care about move to the front instead of getting buried in the wider station traffic.
Choosing one service extends the view beyond the main board. When the response includes stop detail, the tool shows the reported sequence of stops and plots the delay by stop so you can see whether lateness is building, holding steady, or recovering along the run. That is helpful when a train leaves one station a few minutes down but may still reach a later stop closer to time.
A live board is still a forecast, not a promise. It does not replace operator announcements, station displays, or a full itinerary search, and an "On time" label does not mean every detail is final. Use it as a fast station snapshot, then verify again when a missed connection or platform change would be costly.
A strong first pass is simple: enter the station, leave the board on departures if you are catching a train, keep the train-focused filter enabled, and use a 60 to 90 minute window. That gives you a manageable board for most major Swiss stations without mixing in bus, tram, or ship services that can crowd the result.
Change the board to arrivals when you are meeting someone or tracking an inbound service. Add a destination filter when several services share similar names, or type a line such as IC8, IR15, or S2 when you already know the service family and want the board to collapse to a smaller set.
Expected, Platform, and Delay more than the service name alone.The easiest mistake is to treat a green or neutral row as settled fact. Read the selected row first, then confirm the same service in the route view or on the station display before you commit to a tight transfer.
The tool measures timetable drift at the level a passenger actually sees it: planned time versus the latest expected time for the selected station event. For departures it compares scheduled and expected departure timestamps. For arrivals it switches to the arrival timestamps instead. The result is rounded to whole minutes and exposed as the Delay field.
That same logic is repeated for the stop sequence attached to a selected service. Each stop is normalized into planned arrival or departure labels, an optional platform, a delay value, and a status string. The chart then plots the stop delays in order, so the curve reflects how the service is drifting along its route rather than only at the first station you searched.
Swiss customer-information systems do not always show every tiny deviation the same way across modes, but this tracker does not try to mimic every operator display policy. It consistently uses the rounded timestamp difference returned in the live data path and then highlights the result with its own simple bands. That consistency is useful for comparing rows inside the tool, but it also means you should not read its badges as the final word on how a platform display or announcement will be presented.
Delay is the rounded difference between the expected timestamp and the planned timestamp, expressed in minutes.
| Symbol | Meaning | Unit |
|---|---|---|
t_expected |
Latest expected arrival or departure timestamp from the live prognosis path. | Milliseconds |
t_planned |
Scheduled arrival or departure timestamp used as the baseline. | Milliseconds |
d_min |
Rounded delay in minutes, positive for late running and negative for earlier estimates. | Minutes |
If a departure is planned for 10:12 and the expected time moves to 10:15, the tool computes a delay of +3 min. If the expected time is missing, it falls back to the planned time for display, which produces On time. That fallback keeps the board readable, but it also means an apparently punctual row can sometimes mean "no separate prognosis minute supplied" rather than a freshly confirmed zero-delay event.
After station lookup, the tool requests the station board for a specific datetime anchor, board type, result limit, and transport mode set. It then normalizes each returned service into one comparable shape before filtering and sorting.
| Stage | What happens | Why it changes the result |
|---|---|---|
| Station match | The browser searches station-type locations and prefers matches that carry an ID. | A station ID makes the station board request more precise than a loose text label. |
| Board request | The request uses departures or arrivals, the chosen anchor time, and either train-focused or broader transport categories. | Changing board type or transport scope can materially change which rows are returned. |
| Service normalization | Each row is reduced to name, destination, planned time, expected time, platform, delay, cancellation state, and stop sequence. | This is what makes the board, route table, JSON block, and delay chart stay aligned. |
| Window filter | The tool keeps services whose best available time falls inside the anchor window and then trims the list to the requested row count. | Delayed services can move within the list because expected time takes priority when present. |
| Route extraction | The selected service reuses the returned stop list to build stop-by-stop times and delay values. | If no stop list arrives, the route view and chart cannot add deeper context for that service. |
| Output | How it is derived | Boundary rule |
|---|---|---|
Expected |
Expected arrival or departure when provided, otherwise the planned time. | Equal to Departs or Arrives when no separate prognosis minute is available. |
Platform |
Prognosis platform first, otherwise the scheduled platform. | Blank when the response does not include platform data for that row. |
Delay |
Rounded minute difference between expected and planned time. | 0 is On time, 1 to 5 is a small positive delay, > 5 is highlighted more strongly, and < 0 is shown as an earlier estimate. |
Cancelled |
Cancellation flags in the service or prognosis override the numeric delay label. | The textual cancellation state wins even if timestamps would otherwise produce a minute value. |
Route and Delay Chart |
Built from the stop list attached to the selected service. | Unavailable when the service response does not include stop detail. |
Comparisons are most reliable when you keep the same station, board type, anchor offset, and lookahead window. If you change those mid-check, the board may shift because you are no longer measuring the same slice of traffic.
Use this sequence when you want a clean station snapshot first and deeper stop detail only after you find the service that matters.
Station and choose Fetch board. If the page returns No matching station found., retry with the station name rather than a neighborhood or landmark.
Board type to departures for outgoing trains or arrivals for inbound tracking. Use Destination filter or Service or line only after the first fetch if the board is too crowded.
Window & limit so the list matches the period you actually care about. If you need to inspect a later or earlier slice, open Advanced and move Anchor offset instead of guessing from the default time.
Board tab. Compare Departs or Arrives with Expected, note the Platform, and watch the Delay badge in the row and the Rail Snapshot summary.
Route. If the page says the service did not return stop details, refresh or choose another train because this response cannot build the stop-by-stop view.
Delay Chart for the stop sequence trend, or JSON when you need the structured payload. Turn on Auto-refresh only when you are actively monitoring a station and can tolerate repeated public API calls.
The quickest confidence check is the selected row's Expected time plus Platform, followed by a route check if the service is close to a connection edge.
Start with the selected service, not the chart. The most important fields are Expected, Platform, and Delay on the board row you intend to use. The route view and chart add context, but the station-level boarding decision still starts with the currently selected row.
On time means the tool sees no rounded minute gap between planned and expected time. It does not guarantee that the live feed has supplied a separate prognosis minute.+1 min to +5 min is usually a manageable drift. Judge it against your transfer buffer, not in isolation.+6 min or more deserves a slower decision, especially when platform walking time is long or the onward service is infrequent.-1 min is an earlier estimate, not permission to assume the train will definitely depart ahead of timetable.Cancelled overrides all minute math. Treat it as a service disruption and look for alternatives immediately.The main false-confidence trap is reading a calm-looking board as a final operational picture. Verify again when a route view is missing, when the platform is blank, or when the service is sitting near a connection threshold.
You search Bern, leave the board on departures, keep a 90 minute window, and add a destination filter for Zurich. The Board tab shows IC 8 with Departs 14:02, Expected 14:05, Platform 7, and Delay +3 min. That reads as a modest late departure rather than a severe disruption, so the practical question becomes whether your connection margin at the next station is larger than three minutes.
You switch Board type to arrivals and search for the incoming service near the next 30 minutes. The selected row shows Arrives 16:19, Expected 16:18, and Delay -1 min. That does not mean the passenger will certainly walk out a minute early; it means the current estimate is slightly ahead of the timetable, so you should watch the next refresh before leaving the pickup area.
You fetch Zurich HB and select a service whose summary row looks stable, but the Route tab reports that stop details were not returned and the chart cannot add more context. The correction is not to trust the empty route as proof of a direct or steady run. Refresh the board or choose another service, because this response simply did not include the stop list needed for Route and Delay Chart.
No. In this tool it means the rounded difference between planned and expected time is zero. Because the page also falls back to the planned time when no separate prognosis minute is present, a zero-delay row can mean either "matches the live estimate" or "no distinct expected minute supplied."
The page can only build Route and Delay Chart from the stop list attached to the selected service. If that stop list is missing in the response, the board row still works, but the deeper stop-by-stop view cannot be rendered.
No. The package fetches station lookup and station board data directly from transport.opendata.ch in the browser. There is no tool-specific backend file for this slug, so the result depends on live API access.
Turn it off only when you want a mixed public-transport board that can include bus, tram or metro, and ship services in addition to train categories. For ordinary station departure checks, leaving it on usually produces the clearest list.
Station boardPrognosisAnchor timeStop list