Desk case: covering a transit outage live

What to take away

Treat the operator alert as authoritative for service status, not for an unreported cause.
Separate scheduled service, real-time conditions, and emergency instructions.
Verify station access and accessible alternatives before publishing them.
Correct the current summary as well as the mistaken post.
Close the live page when service stabilizes and investigation slows.

This fictional case uses an invented transit agency, city, routes, stations, passengers, records, and times. Federal transportation sources support the communication and data distinctions used in the reporting method. They do not support any fictional event.

7:14 a.m.: the first alert

The fictional Harbor Metro posts that Blue Line trains are suspended between East Market and River Terminal "because of an operational issue." Riders report smoke at East Market. A local account claims a train caught fire.

The desk opens a live page with a narrow scope: verified service status, public instructions, and agency response. The first post does not state a fire. It attributes the smoke reports and says their cause is not confirmed. The roles and claim queue follow how to run a live update desk.

Build the source board

Source	What it can establish now	What it cannot establish now
Harbor Metro alert	Suspended segment and official instructions	Mechanical cause unless stated
Fire department dispatch	Units sent and incident location	Final cause or transit restoration time
Rider account	What the named rider observed	Conditions across the whole line
Static schedule	Planned service	Current operation during disruption
Real-time feed	Reported live service fields	Cause outside the feed's data

The desk assigns one reporter to the operator, one to emergency services, and one to rider access. This prevents three editors from calling the same spokesperson while elevator and shuttle questions go unanswered. Role assignment against a known clock looks different; compare the jobs report release day case.

7:26 a.m.: rider instructions

Harbor Metro announces replacement buses from East Market but does not name pickup points or accessible boarding locations. The desk reports that buses are planned and asks for the missing details. It does not tell wheelchair users to travel to an unverified stop.

The U.S. Department of Transportation transportation and emergency checklist calls for accessible communications and broad publication of staging and pickup or drop-off locations for people who need transportation assistance. The fictional agency is not being graded against that checklist. The source supports the newsroom's decision to verify location and accessibility details before presenting a shuttle plan as usable guidance. The service impact checklist holds the desk to those fields: who qualifies, where, when, and through which office.

7:41 a.m.: the first error

A reporter hears a fire official say "electrical odor" during a noisy phone call. The live post mistakenly says the department confirmed an electrical fire. Three minutes later, the recording review shows the official did not say fire.

The desk marks the post corrected, states the inaccurate wording, replaces it with the confirmed dispatch and odor report, and updates the pinned summary. It notifies the social editor because a headline card repeated the error. Downstream repetition is a classic failure; live update problems and fixes catalogs it with the dependency-list remedy.

8:05 a.m.: distinguish data layers

The operator's trip planner still shows scheduled trains through the closed segment while its alert feed shows suspension. The article explains that a schedule and a real-time alert are separate data products rather than calling the planner screenshot proof that trains resumed.

An FTA report on open-data policy guidelines for transit discusses separate schedule, real-time, and alert feeds and describes systems that unify internal alerts for public distribution. The report does not verify Harbor Metro's fictional feeds. It supports treating those data types separately and checking which one a rider-facing tool currently uses.

The desk tests the trip planner at two times, saves screenshots, and asks the operator when the planned schedule will reflect the disruption.

8:32 a.m.: cause remains open

The fire department says there was overheating in trackside equipment and no train fire. Harbor Metro says engineers are inspecting a power component. The desk reports both statements with their scopes. It does not convert "overheating" into a final failure cause.

The pinned summary now states:

service remains suspended on the named segment;
replacement buses use two confirmed pickup locations;
one location has an accessible boarding area;
emergency crews found overheated equipment;
the technical cause and reopening time remain unknown.

9:18 a.m.: partial service returns

Harbor Metro restores trains to one station and keeps the final section closed. The desk changes the map and every affected instruction. An older post stays in the chronology with its time, but a note points readers to the current summary.

The team avoids saying the line "reopened" without the segment limit. It names direction, stations, remaining shuttle route, and the operator's next update time.

10:06 a.m.: close the live page

Full service resumes with residual delays. The cause moves to a slower technical review. The closing note states the final service status, reporting cutoff, corrected fire claim, and open investigation question.

The follow-up assignment requests maintenance records, the incident report, feed logs, passenger-access review, and the operator's explanation for the stale trip planner. The live page remains a dated record rather than becoming an undated service guide.