A storm rolls in and you cancel the 2pm sailing. You post it on Facebook. You update the notice board at the terminal. But the family already driving there is looking at Google Maps, which still shows the 2pm departure running on time — because your website and Google Maps have never talked to each other.
That gap, between “we cancelled it” and “the passenger found out,” is where ferry operators lose trust and take the angry phone calls.
Static GTFS vs. GTFS-Realtime, in plain English
Static GTFS is your timetable, published as a feed. It’s what puts your sailings into Google Maps, Apple Maps and other journey planners in the first place — someone searches “ferry to [island]” and your times show up. It’s set up once and updated when your schedule changes.
GTFS-Realtime is the live layer on top: “this specific sailing is delayed,” “this one’s cancelled,” “the vessel is here right now.” It updates continuously, and it’s the part almost no ferry-booking platform produces — which is exactly the part that matters most for a ferry operator.
Why this is a ferry problem more than a bus problem
Ferries are weather-exposed in a way scheduled bus routes usually aren’t. Cancellations and delays are routine across a season, not a rare exception. And a cancelled sailing strands people who are often already at the terminal, having driven there — the cost of stale information is higher than a bus you just catch ten minutes later. Add in seasonal or tidal schedule changes, and you’ve got exactly the conditions where a live feed earns its keep.
For a ferry operator, GTFS-Realtime isn’t telemetry for its own sake — it’s cancellation communication that reaches the passenger where they’re already looking, the map, without spending anything extra on ads or SMS to do it.
“But I already post cancellations on Facebook and our website”
Sure — and that reaches people who already follow you, or think to go check. It doesn’t reach the passenger who searched once, weeks ago, and is now mid-journey with the map open. That’s a different audience, and it’s one you can’t otherwise touch. A GTFS-Realtime feed also flows through to any other transit app or journey planner that consumes it, so one update multiplies out further than a single social post.
What it actually takes
You don’t hand-code any of this. In AddTransit, a cancellation or delay is flagged as a Realtime Status update from your dashboard — you choose what’s affected (a route, a trip, a stop) and why, and that becomes a real GTFS-Realtime Service Alert, the same standard Google Maps and other journey planners read. It’s a short form, not something you or your IT team have to touch. Behind the scenes, GTFS-Realtime feeds use a technical format called protobuf, the same one Google Maps requires — normally something you’d need a software engineer to produce.
AddTransit generates it for you automatically the moment you publish the update, so you get a real, spec-compliant feed without writing a line of code. It is a deliberate step from your dashboard rather than something that fires itself, though — so it’s worth building “flag the cancellation” into your actual weather-day routine, not assuming it happens automatically.
This is what makes AddTransit’s setup comprehensive: static GTFS, the live realtime layer, and ticketing all run from the same platform, on the same feed, under the same account. Your schedule, your live cancellation alerts, and your bookings are connected end to end — not stitched together from separate tools.
Is this for you?
If you run two sailings a day on a timetable that basically never changes, static GTFS alone is probably enough, and you don’t need to think about GTFS-Realtime any further. If your season is weather-driven and your phone rings every time the map is wrong, the realtime layer is the difference between passengers finding out from Google Maps and finding out from an angry voicemail.
See how a flagged cancellation becomes a live map update →
This post is written by the AddTransit team — we build the GTFS + GTFS-Realtime + ticketing platform described above, so take the framing with that in mind. The underlying gap between static and real-time GTFS is real whichever tool you use.
