The Stage Timer That Counted Up Instead of Down: A Standardized Speaker Protocol

A countdown that runs the wrong way is rarely a button mistake. It is almost always a clock-source mismatch: the display is computing remaining time from a clock that moved backward, or from a local timer that was never anchored to the operator’s source. Treat it as an architecture problem, not a firmware patch.

This is a protocol for the people who own the clock on show day — the showcaller at the desk, the stage manager on the floor, and the speaker who only reads. It separates two timing jobs that get conflated, names who owns what, and ends with a copyable checklist you can hand out at load-in.

Two timing jobs, not one

Every stage timer does two different things, and they have different requirements.

Job one: measure elapsed time. This needs a clock that only moves forward. The W3C High Resolution Time specification is explicit about why: a computer’s wall clock sometimes needs to be adjusted, which means its value can decrease, making it unreliable for measurement or for recording the order of events. The same specification notes that a duration computed from two wall-clock readings can come out positive, negative, or zero. A negative duration is exactly what a count-up looks like on a countdown display.

Job two: show one remaining time to several screens. This needs a single authoritative source that every display reads, so the lectern, the wings, and the green room cannot drift apart. It is a distribution problem, not a measurement problem.

Most counting-up failures come from using a wall clock for job one. The fix is to derive elapsed time from a monotonic clock and derive remaining time as duration − elapsed, then distribute that one value.

Why the wall clock is unsafe for a countdown

The monotonic clock, per the same W3C specification, never decreases and cannot be changed by system clock adjustments. That is the property a countdown needs. If your display computes remaining time as end_time − Date.now(), any backward adjustment to the system clock — a time sync correction, a manual fix, a device waking from sleep with a stale clock — turns your remaining time into a larger number. The display counts up.

The monotonic clock has a limit you must design around: it exists only within a single execution of the user agent, so it cannot be used to compare events across different executions. In practice, that means a browser tab that reloads, a display that reboots, or a tablet that reconnects cannot carry its own monotonic reading across the gap. It must re-anchor to the operator’s source on reconnect rather than resume a private timer.

That is the architectural rule: monotonic for elapsed, one shared source for remaining, re-anchor on reconnect.

The operator/display split

The pattern that prevents most of this is a strict split between control and read. In the stage-timer product documentation reviewed for this article, the desk runs a single countdown and the floor reads it; both read the same server clock. The Stage display is read-only — nobody can start or stop the clock from the floor — and a Stage screen that reconnects picks the live countdown back up rather than running a private timer.

That last property is the one that matters most for the counting-up failure. A display that reconnects to a shared source cannot invent its own direction. A display that resumes a local timer can.

Write the split into the run-of-show so nobody has to negotiate it at 09:55:

  • Showcaller owns the clock and the rundown: start, pause, adjust, advance, and the message to stage.
  • Stage manager owns the displays and their links: which screen is where, that it is showing the right segment, and that it is read-only.
  • Speaker owns only the read. No controls on the floor, by design.

Make zero a defined state

Ambiguity at zero produces both overruns and abrupt cutoffs. A published presentation-timer pattern recommends deciding in advance whether zero means “finish the current sentence” or an immediate stop. The same pattern uses green while more than 20 percent remains, amber during the final 20 percent, and red at zero — a cue scheme the speaker can read at a glance without parsing digits.

Pick one rule per event and put it on the speaker card. If your timer counts into overtime, confirm before doors that the desk and the floor show the same overtime state; the product documentation reviewed here states that when a segment hits zero the timer counts into overtime and Control and Stage show the same colour. If your timer stops at zero, say so, and name who calls the stop.

Rehearse the failure, not just the talk

A two-minute pre-show drill on the actual venue hardware will surface a direction bug before the audience does. The drill has four steps:

  1. Confirm direction. Start the countdown and watch the lectern display for 10 seconds. The number must go down. If it goes up, stop and fix the source before anything else.
  2. Pause and adjust. Pause, add one minute, resume. Confirm the floor display follows within a second and the direction is still down.
  3. Force a reconnect. Disconnect the floor display’s network, wait 10 seconds, reconnect. Confirm it re-anchors to the live countdown rather than resuming a private timer.
  4. Check the fallback. A browser cannot continue showing cues after it is closed, and a display can be closed, throttled, or put to sleep. Name a second screen or a human timekeeper for any segment where the clock is load-bearing.

Test full-screen behavior on the actual projector or conference screen, not on the laptop in the production office. The published guidance is blunt about this, and it is right: the venue hardware is where full-screen and sleep behavior differ.

Label displays by location, not by device

Name each display link by where it lives — Lectern, Wings, Green Room, Gallery — rather than by the tablet’s asset tag. When a device is swapped or a screen reconnects, the link name still tells you which physical position it serves, and a swapped tablet cannot silently attach the wrong screen to the wrong segment.

After the show, revoke the links. The product documentation reviewed here recommends regenerating or deleting each Stage link after every show so the old URLs stop working straight away. An unrevoked link is a live countdown anyone with the URL can open.

What this protocol does not claim

This article does not describe a specific reported incident in which a stage timer counted up; the failure mode is presented as an illustrative diagnosis, not a case record. It also does not claim that NTP, PTP, or SMPTE ST 2059-2 is required for, or used by, conference stage timers. Those standards describe network and broadcast synchronization, and the retrieved documents do not establish a link to event stage clocks. If your venue runs PTP for broadcast infrastructure, that is a separate conversation from the speaker clock.

What the sources do support is narrower and sufficient: wall clocks can decrease, monotonic clocks do not, monotonic readings do not survive across executions, and the operator/read-only-display pattern with re-anchor on reconnect is a documented way to keep the desk and the floor on one clock.

Copyable artifact: Speaker Clock Protocol

Hand this to the showcaller and stage manager at load-in. One page, no prose.

SPEAKER CLOCK PROTOCOL — SHOW DAY
Event: ____________________  Date: __________  Showcaller: ____________
Stage manager: ____________  Fallback timekeeper: ____________

1. SOURCE
   [ ] One authoritative clock source named: ____________________
   [ ] Desk and all floor displays read that source (not local timers)
   [ ] Remaining time derived from monotonic elapsed, not wall-clock subtraction

2. ROLES
   [ ] Showcaller: start / pause / adjust / advance / message
   [ ] Stage manager: displays, links, segment match, read-only confirmed
   [ ] Speaker: read only — no controls on the floor

3. DISPLAY LINKS (name by location)
   [ ] Lectern      link: ____________  tested: __
   [ ] Wings        link: ____________  tested: __
   [ ] Green Room   link: ____________  tested: __
   [ ] Gallery      link: ____________  tested: __

4. ZERO RULE (circle one)
   (a) finish the current sentence   (b) immediate stop
   Overtime shown as: negative time / colour change / not shown
   Who calls the stop: ____________

5. PRE-SHOW DRILL (on venue hardware, 2 minutes)
   [ ] Direction: number goes DOWN for 10 s
   [ ] Pause + add 1 min: floor follows within 1 s, still down
   [ ] Reconnect: floor re-anchors to live countdown, no private timer
   [ ] Full-screen tested on actual projector / confidence monitor
   [ ] Display sleep disabled; tab cannot be closed by floor staff
   [ ] Fallback named for load-bearing segments: ____________

6. AFTER SHOW
   [ ] Revoke / regenerate all display links
   [ ] Note any direction, reconnect, or drift issue in the post-mortem

SPEAKER CARD (hand to each speaker)
  - The clock counts DOWN. Green = go, amber = land the ending, red = zero.
  - At zero: ____________________ (per rule 4 above)
  - The clock is read-only. If it looks wrong, keep talking; the desk will fix it.

The drill in section 5 is the part people skip. It takes two minutes and it is the only step that catches a counting-up display before the room fills. Run it on the venue hardware, every show, and log the result in the post-mortem so the next load-in starts from a known state.

Questions operators actually ask

Why does the display count up instead of down?

Most likely the display is computing remaining time from a wall clock that moved backward, or it resumed a local timer after a reconnect instead of re-anchoring to the shared source. Check the source first, then the reconnect behavior.

Can I just use a phone stopwatch as a backup?

As a fallback for a load-bearing segment, yes — but name the person holding it and the cue they will call. A stopwatch measures elapsed time; it does not show the same remaining time to the floor, so it is a human fallback, not a second clock.

Does a monotonic clock keep two screens in sync?

No. The monotonic clock exists only within a single execution and cannot be compared across separate executions. Cross-screen agreement comes from every display reading one shared source, not from each display running its own monotonic timer.

What should the speaker see at zero?

Whatever you decided before doors: finish the sentence, or stop. Put it on the speaker card and confirm the desk and floor show the same state. The failure at zero is almost always an undefined rule, not a broken timer.