Real-time information is valuable, but a public website should never become confusing just because one data source has a bad day. An integration can fail for ordinary reasons: a vendor service is temporarily unavailable, a network connection is interrupted, an authorization setting changes, or a new format reaches the website before it has been tested.
The worst outcome is a blank alerts page that looks like “no service issues” when the agency simply has no fresh data. The better outcome is a calm, intentional fallback.
Separate “no alerts” from “no current feed”
Those two messages mean different things. If the feed is healthy and there are no active incidents, the page can say so plainly. If the website cannot confirm current feed information, it should avoid implying that service is normal. A short, staff-controlled message can direct riders to the most appropriate channel while the connection is restored.
Build a practical fallback
- Record the time of the last successful update.
- Alert the people responsible for the website before riders discover the problem.
- Keep a manual publishing path available to communications staff.
- Make the fallback message specific: explain the information gap without guessing at service conditions.
- Test the recovery process, including what happens to alerts when fresh data resumes.
This is not an argument against automation. It is an argument for treating the website as a public service, not a passive screen. The integration should reduce work on normal days while still giving people a dependable way to communicate on unusual ones.
A rider does not need to know which system is having trouble. They need an honest signal about the confidence of the information in front of them and a clear next step.