A transit website may have two valid sources of service information: an operations feed with disruption data and staff notices that explain the practical consequences. Combining them requires clear ownership. The website should help riders understand both sources without asking staff to retype every automated update or suggesting that one source contains the complete picture.
Our CARTA work connected Swiftly service-alert information to a WordPress service-notifications page alongside staff-managed notices. The implementation kept those sources distinct while bringing them into one place to check. That distinction matters: automation can supply current operational details, while staff can add information that requires local judgment.
Keep the source responsibilities clear
Swiftly’s passenger-information tools distribute real-time transit information. In the CARTA implementation, the WordPress integration reads the service-alert feed, interprets the supplied alert periods, and prepares the information for display. Where the feed provides them, detail cards can include affected routes, stops, descriptions, and start or end times.
Staff notices follow their own editing path. A holiday explanation or a local service message does not have to be forced into a feed-shaped record simply to appear on the same page. Keeping the sources separate also makes it easier to explain which system should be used when a correction is needed.
Feed-supplied disruptions, routes, stops, and available timing details.
Locally written explanations and other service information.
WordPress service-notifications page
Distinct source types, readable details, and visible feed availability.
The diagram describes the content paths; it does not mean that WordPress replaces the operations platform or automatically reconciles every overlapping message.
Make availability part of the information
An empty alert list and a failed connection mean different things. A successful response may contain no active feed alerts. An unavailable response means the website cannot currently confirm what the feed contains. Presenting both as “no disruptions” would give riders more certainty than the system has.
The reviewed CARTA implementation includes a bounded fallback to previously fetched information. It can use a cached result within a fifteen-minute window and mark updates as delayed on the detail page. When that fallback is no longer available, the page has an explicit unavailable state. Staff-managed notices remain separate from the feed’s availability.
That fallback window measures the age of the stored fetch; it should not be read as a guarantee that every upstream alert was recently authored. Distinguishing those timestamps is an important review question for any feed integration. Our guide to handling an unavailable Swiftly feed looks more closely at the reader-facing choices.
Be precise about time and status
Timing fields need agreed meanings. A feed’s active period, a staff notice’s displayed date, and a scheduled publication time are not automatically equivalent. During review of this implementation, a future start date on a manual notice did not, by itself, guarantee delayed publication. That is a useful reminder to test the actual publishing behavior before relying on a field label.
For a transit team planning similar work, write down which notices are active, which should remain available as past information, and who is responsible for ending or correcting a message. Our article on automated versus manual alert ownership provides a starting point for that discussion.
Verify the difficult states
The CARTA release records include source checks, direct API checks, and seventeen offline behavioral fixtures covering feed, cache, and manual-notice behavior. Those checks support the implementation description here. They do not establish a measured reduction in support calls, a ridership improvement, or a complete accessibility audit.
A useful acceptance checklist for a similar project includes a normal feed response, no active alerts, a temporary outage, an expired fallback, a staff notice without feed data, and a notice affecting a specific route. Review each state on mobile and with assistive technology. In particular, confirm that a rider can distinguish “nothing active” from “information unavailable.”
The transferable lesson is to combine the reading experience while preserving source ownership. Riders need a clear account of what is known and what to do next. Staff need a dependable editing process. A successful integration should make both responsibilities easier to understand.