Guides
Part of Breaking news updates and timelines: a reporting guide
How to run a live update desk
Live update desk workflow for roles, claim checks, timestamps, current summaries, accessible refreshes, visible corrections, shift handoffs, and closure.
What to take away
- Separate intake, verification, writing, and publishing roles when staffing allows.
- Give every claim a source, status, time, and owner.
- Maintain one current summary independent of the chronological stream.
- Design updates so screen-reader users can detect changes without disruption.
- Close with an archive note and a handoff to slower reporting.
A live desk works best as a controlled pipeline. The goal is not to make every reporter publish faster. It is to reduce duplicated requests, expose weak evidence, and keep the public version consistent while facts change. The desk's output format is the live page described in the breaking updates and timelines guide; this article covers the workflow behind it.
Photo and credit
The photograph shows historical election-night newsroom work. It does not depict any current event, desk, or workflow described here.
Step 1: assign roles
One person may hold several roles on a small desk, but the responsibilities should remain distinct:
| Role | Primary duty |
|---|---|
| Intake editor | Logs incoming records, calls, images, and tips |
| Verification editor | Checks identity, time, location, content, and source authority |
| Live writer | Drafts one focused update from cleared material |
| Publish editor | Reviews wording, status, safety, and timestamp |
| Summary editor | Maintains the pinned current state |
| Field coordinator | Protects reporters from repeated desk requests |
Name one decision maker for disputed publication calls and one correction owner.
Step 2: use a claim queue
Each queue item should contain the exact claim, source, event time, source-release time, location, verification performed, confidence label, safety concern, assigned editor, and dependent updates. Do not let a screenshot become a source record without its original page or sender.
Screenshots of phone alerts deserve the same discipline. FEMA's page on Wireless Emergency Alerts says the messages come from authorized federal, state, local, tribal, and territorial alerting authorities, display the issuing agency and recommended action, and run no more than 360 characters. Confirm the full instruction on the named issuer's own channel before quoting an alert into the stream.
Mark a claim cleared only for the wording the evidence supports. A transit operator may confirm that a station closed; it may not yet know the cause. Service claims like that one have their own field list in the service impact checklist.
Step 3: publish complete small units
Each post should answer:
- What is new?
- Who knows or says it?
- When and where does it apply?
- What does it change for readers?
- What remains unconfirmed?
Place attribution before a disputed claim can be mistaken for the newsroom's finding. Use direct quotations only when the exact words matter.
Step 4: protect the current summary
The summary is not a list of recent posts. It is the desk's present answer. Give one editor control so simultaneous changes do not produce conflicting versions. Time-stamp it and state the next expected check. Overnight, the same discipline feeds the morning news brief, whose items also lead with the present answer.
Review the summary after any correction, major official statement, boundary change, casualty update, reopening, or shift in investigative status.
Step 5: make dynamic updates accessible
The W3C explanation of WCAG status messages says users of assistive technology should be informed of important content changes that occur without taking focus. It distinguishes status information from every new result and warns through its techniques against unnecessary interruption. A live news page needs product testing to apply the standard correctly, but the principle is clear: new content cannot rely only on visual movement or color.
Use proper headings, semantic time elements, descriptive update labels, keyboard access, and a readable chronological option. Avoid forcing the page to jump when a new post appears. Let users pause automatic refresh or receive a controlled notification.
Step 6: run scheduled checks
Every 20 to 30 minutes, or at a pace suited to the event, check:
- Does the headline still match the verified situation?
- Is the summary current?
- Are time zones consistent?
- Did a source revise or remove a statement?
- Are rumors being repeated in debunks without need?
- Does any update expose a vulnerable person or active operation?
- Are multiple posts repeating one source?
The check does not replace review of each post. It catches drift across the page.
Step 7: correct and communicate
Freeze the affected claim, trace every use, publish the correction, and update the summary. Tell field and audience teams what changed so an old version is not redistributed.
Preserve the wrong wording in the correction note when readers need it to understand the change. Do not repeat harmful personal details more than necessary.
Step 8: close and hand off
When live coverage ends, state the closing time, current result, unresolved questions, and where the next reporting assignment begins. Export the claim queue and correction log to the follow-up team. Archive the page as a dated record rather than silently maintaining it as evergreen guidance. The follow-up piece is usually an explainer; the daily news explainer guide describes that slower format.
Common questions
Can one editor run a live page alone?
Yes for a limited event, but the editor still needs explicit intake, verification, publishing, summary, and correction checks.
Should new posts automatically move focus?
Generally no. Automatic focus changes can disrupt readers. Use tested accessible status behavior and user controls.
When should comments or eyewitness tips be published?
Only after verification suited to the claim, with clear attribution and attention to safety, privacy, and possible harm.
Who decides when the live page ends?
The assigned editor, using the event's pace, reader need, verification capacity, and planned end condition.