Real-time showflow updates: getting a change onto every device

The running order exists in more places than anyone tracks: the show caller's screen, a stage manager's tablet, the graphics operator's second monitor, a printed sheet at front of house, and the version someone exported to PDF on the train. Change one and every other copy is wrong until a human remembers it exists. Real-time updating is not a convenience feature; it is the removal of that reconciliation step.

The dangerous state is not "out of date". It is "partly up to date". A crew that knows the sheet is from this morning will check before acting. A crew that believes the sheet is live, when three of the seven devices did not receive the last change, will act on it.

Used precisely, it means a change made in one place appears on other connected devices without anyone refreshing, reopening or re-exporting anything. Used loosely, it can mean a page that polls every thirty seconds, which is a materially different promise during a show.

The distinction that matters operationally is not the latency figure. It is whether a device can tell you that it is currently connected. A screen showing stale data indistinguishable from live data is the failure mode; a screen that says plainly that it has lost contact lets the person holding it fall back to comms.

Push, not poll

The change is sent to connected devices when it happens, rather than found the next time a device asks.

A visible connection state

The single most important element on a live device. Connected, reconnecting, offline — never ambiguous.

Reconnect and catch up

A device that drops for ninety seconds must come back to the current state, not to the state it left.

One source

If the tablet is reading an export rather than the record, none of the above helps.

Assume the network will fail, because at venues it does. Basements, marquees, exhibition halls with ten thousand phones on the same guest wifi, and back-of-house corridors are all reliably bad. Plan for the device that loses contact rather than for the one that does not.

A device that goes quiet is a problem. A device that goes quiet without saying so is an incident.

The practical mitigations are unglamorous and they work: put critical positions on hardwired ethernet where the venue allows it, keep a cellular fallback for at least the show caller, print a paper running order at the last responsible moment and mark it clearly with the time it was printed, and rehearse the failure — actually pull the network in rehearsal and watch what the devices do.

The printed sheet is not an admission of defeat. It is the fallback, and the timestamp is what makes it safe: a sheet marked with the moment it was printed can be reasoned about, while an undated printout cannot.

This is a discipline question that software can support but cannot answer. During a show, one person edits the running order. Everyone else raises the change to that person over comms.

The reason is not politics. If two people can move the same item, the record stops being a shared truth and becomes a negotiation, and the crew loses the one thing that made it worth trusting. Decide who holds the pen before doors, say it out loud in the briefing, and make sure the rest of the team know how to reach them.

Everything above applies whatever you run the show from. This is EventBlok specifically.

In EventBlok the showflow is a live view of the same programme the agenda publishes rather than an exported document, so there is no version to distribute and nothing to reconcile. A change to a session moves its cues with it, and the published agenda, speaker pages and signage views read the same record.

For how that propagation works across surfaces, see how a change reaches every screen; for the editorial side of announcing changes to attendees, see managing live agenda changes.

Founder, EventBlok. Live, hybrid and broadcast producer, showcaller and technical director, in production since 1996.

About EventBlok