How to Keep Several Stage Timer Screens in Sync
Stage & venue setup9 min readUpdated
Two timer screens disagree for one of three reasons: they were never running the same timer, the update from the controller reached them at different moments, or the devices' own clocks disagree. The first is a setup mistake, the second is the network, and the third is the one people rarely check: the time setting on each device. Fix all three and the screens should agree to within a moment.
Why it matters
A speaker who sees 3:00 on the floor monitor while the stage manager's screen says 2:40 will get two different signals, and the moderator watching a third screen will cut in at the wrong moment. A few seconds rarely matters for a 20-minute keynote; it matters a lot for a two-minute pitch, a debate rebuttal or a live broadcast cue.
The three ways multi-screen timers are built
How a system keeps screens together decides how it can drift apart.
1. Each device runs its own timer. Two phones running stopwatch apps, or two laptops each started by hand. They are only as close as the moment someone pressed start on each, and any pause, adjustment or restart has to be repeated on every device. This is the setup that produces the biggest disagreements, and they never correct themselves.
2. One source sends the same picture to every screen. A single computer runs the timer and its video output goes to every monitor by HDMI or SDI, through a splitter or switcher. The screens can't disagree, because they are all showing one signal. The cost is cable to every screen.
3. One source of truth on a network. A controller or server holds the timer, and each display is a separate device that connects to it, which is how web-based timers work. The browser's WebSocket API opens a two-way connection between a page and a server, so a page can receive updates without having to poll the server for them, and displays can hear about a start, pause or adjustment as it happens. Within this approach there are two designs:
- The server sends every tick. Each screen shows whatever it last received. Simple, but every second of display depends on the network, and a screen whose connection hiccups freezes until the next update arrives.
- The server sends the timer's state, and each screen counts locally. The server says, in effect, "this segment ends at this moment", and each device works out the remaining time from its own clock. Counting is smooth even if the network stutters, but now every device's clock has to be right.
Network delay: what it does and doesn't cause
An update takes time to travel from the server to each screen, and a screen on congested Wi-Fi gets it later than one on a cable. In a system that re-sends the timer's state regularly, this shows up as a brief lag when the operator presses start, pause or adjust. It should not build up over time, because the next update brings every screen back to the same state.
If one screen is consistently slower to react than the others, look at its connection first: weak Wi-Fi signal, a crowded guest network, or a device that keeps dropping and reconnecting.
Device clocks: the cause nobody checks
The clock inside a computer, tablet or phone doesn't run at exactly the right rate. Time engineers call this drift: the NTPsec project's glossary defines it as the frequency offset of a clock crystal that makes the system time drift slowly. It is usually expressed in parts per million and changes slowly in response to environmental factors, mainly ambient temperature.
Devices correct for this by regularly checking their time against time servers using the Network Time Protocol. NIST, for example, runs an Internet Time Service that is directly traceable to UTC(NIST), its official time reference, and describes NTP client software as running continuously as a background task that periodically gets updates from one or more servers (NIST page, updated June 2026). Devices with automatic time turned on typically handle this for you.
So a device that has automatic time switched off, or that has been offline or blocked from reaching time servers, can be wrong, and its error can keep growing the longer it goes uncorrected.
This matters for any timer that counts locally against a timestamp. A browser page that uses the standard JavaScript clock is relying on the device's system time; MDN notes that Date.now() may be affected by system and user clock adjustments and clock skew because it depends on the system clock. If a tablet's clock is two seconds fast, a timer that counts from the server's timestamp on that tablet will show two seconds less remaining than a correctly set screen beside it, and keep doing so.
How to keep screens in sync
- Use one source of truth. Never run separate timers on separate devices for the same segment.
- Turn on automatic time on every display. On iPad: Settings > General > Date & Time > Set Automatically (Apple). On Windows 11: Start > Settings > Time & language > Date & time > "Set time automatically" (Microsoft). On a Mac, the same Apple article covers the Date & Time setting.
- Use the same network for all displays, wired where you can, and keep display devices off congested guest Wi-Fi.
- Keep devices awake and dedicated. A tablet that slept and woke up, or a browser tab that was in the background, may take a moment to catch up. Setting up a stage timer on any screen covers sleep, notifications and full screen.
- Use video distribution for critical screens. If two screens must match exactly (a broadcast cue screen and a stage screen, for example), feeding both from one computer's video output removes the question.
How to test sync before the show
- Side-by-side check. Put every display where you can see them together, or film them on one phone, and compare the seconds.
- Control test. Start, pause, add a minute, skip to the next segment. Every screen should respond within a moment of each other.
- Idle test. Leave the timer running untouched for longer than a typical segment and compare again. A gap that grows points to a frozen screen or a separate timer; a gap that stays the same points to a device clock.
- Reconnect test. Turn one display's Wi-Fi off for a few seconds, then on. It should recover by itself and match the others.
- Full-room test. Repeat the side-by-side check once the audience's phones are on the network.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| One screen is a fixed number of seconds off, all the time | That device's clock is wrong | Turn on automatic time, then reopen the timer page |
| One screen lags when the operator presses a button | Weak or congested connection | Move it to a better network or a cable |
| A screen froze and doesn't move | Lost connection, the device slept, or the tab was suspended | Check its network and sleep settings, then reload the page |
| Screens were different from the start | Separate timers started by hand | Switch to one controller driving all screens |
| Everything is out by the same amount versus the run of show | The operator started late, not a sync problem | Adjust the timer from the controller |
Reloading a display page is a sensible first fix. When the server holds the timer's state, as it does in StageClock, a reloaded page should pick up the current state, but that isn't documented, so try it during your test run rather than assuming it.
How StageClock does it: the server owns the timer and pushes an update to every connected screen over a WebSocket whenever the producer acts, plus a full state refresh every 5 seconds. Each screen then counts down locally using its own device clock against the server's timestamp, with no correction for a device whose clock is off, so turning on automatic time on every display device matters. Sync is automatic (there is no re-sync button), screens reconnect by themselves (the Stage Display shows a "Reconnecting…" badge meanwhile), and an internet connection is required.
Running several rooms adds another layer, since each room needs its own timer and its own checks; running multiple rooms and tracks covers that. For the wider trade-offs between cabled hardware and network timers, see hardware vs web-based stage timers, and for the basics, the stage clock guide.
Frequently asked questions
Does a faster internet connection fix sync problems?
Not by itself. Speed helps with the delay when updates arrive, but a stable connection matters more than a fast one, and no connection speed fixes a device whose clock is set wrong. Check automatic time first, then connection stability.
Can I use the venue's existing wall clocks as a reference?
Only if you know how they are set. Networked clocks that take their time from a time server will agree with correctly set devices; a battery wall clock set by hand may be minutes out. Use your timer system as the reference for speakers, not the wall.
Key takeaways
- Screens disagree because of separate timers, network delay, or wrong device clocks; check all three.
- Always drive every screen from one source of truth, never separate timers started by hand.
- Turn on automatic time on every display device, because timers that count locally rely on the device's clock.
- Network delay should cause a brief lag on button presses, not a growing gap; a growing gap points to a frozen screen or a separate timer, and a constant gap to a device clock.
- Test side by side, idle, after a reconnect and again with the room full.