April 2026 · 5 min read · Setup & workflow

Debate timer on two devices: how judge-debater sync actually works

TL;DR

Running the timer on two devices — the judge's phone for controls, the debater's laptop or tablet for a big read-only countdown — removes the awkwardness of asking "how much time do I have?" mid-speech. Modern browser tools do this with a shared room code and WebSocket sync, no signup or app install. The judge stays in control; the debater just watches.

For years, the default debate-timer setup was one phone, held by the judge, tilted toward the debater whenever they needed to see the clock. It worked because there wasn't a better option. Every debater has spent at least a few rounds half-craning their neck to catch a glimpse of the timer between arguments.

Browser-based timers changed the math. When the timer runs in a webpage and two devices can share a session, the judge keeps a controller on their phone and the debater gets a full-screen countdown on their own laptop. They don't interrupt each other. Nobody has to lean across the table.

The magic is in the sync. Here's how it actually works.

The model: one room, two roles

Every round creates a room — a short identifier, usually a 6-character code. Any device that knows the code can join the room. Inside, devices play one of two roles:

When the judge taps Start, the controller sends a message to the room: "speech started at time X." Every display device in that room receives that message and updates its countdown to match. If the judge hits Pause, a pause message goes out and both screens freeze at the same moment.

Why it feels instantaneous: the sync transport is WebSockets, which keep a persistent connection open between each device and a tiny coordination server. Messages propagate in tens of milliseconds — faster than the debater's eye can register the clock changing. It feels like one timer, not two.

How devices join a room

Three common ways, in order of practicality at an in-person round:

1. QR code pairing

The judge's controller displays a QR code. The debater points their laptop camera or phone camera at it and the browser opens the display URL with the room code already in it. Total setup time: about 4 seconds. This is the method that works best at a tournament where the judge is managing time pressure between rounds.

2. Copy-paste link

The controller has a button that copies the room URL to the clipboard. The judge pastes it into whatever's handy — iMessage, Discord, email — and the debater clicks it on their end. Works well for remote rounds where a QR code isn't an option.

3. Typed room code

The room code is displayed as plain text (e.g. K7M2XR). The debater types it into a "join room" field on a separate device. Less common, but useful when the camera is dead or the copy-paste path is inconvenient.

What the sync actually carries

This is where the engineering nuance matters. There are two ways to transmit timer state, and only one of them is reliable.

Naive approach: the controller sends the current countdown value (e.g. 4:32) every second. Every display receives it and renders it. Problem: any network hiccup makes the display skip or stutter. Problem: two displays might show slightly different values if their messages arrive out of order.

Better approach: the controller sends the timestamp at which the current speech started, plus the speech duration. Every display computes "remaining time" locally by subtracting the current time from the start timestamp. Messages only need to fire on state changes — start, pause, reset — not every second.

This is drift-proof. If a device reconnects after a 20-second network blip, it gets the current speech's start time and can compute exactly where it should be. No catch-up animation. No jumps.

Where sync changes the round experience

Scenario: LD round, flow-heavy case

The affirmative is deep in a rebuttal, flipping flow sheets, running sub-points. They know they need to wrap up soon but don't want to interrupt their rhythm by glancing away.

Without two-device sync, they'd have to pause, look at the judge's phone across the table, process the time, and resume. Maybe 3 seconds, but enough to lose the thread of the argument.

With two-device sync, the laptop in front of them is already showing 0:42 in large type. One peripheral glance, no pause, no rhythm break. They wrap in time.

Scenario: PF round, crossfire

Four speakers are standing for grand crossfire. The judge is taking notes. No one wants to interrupt to ask how much time is left.

With a shared display, a laptop at the front of the room shows the crossfire clock to all four debaters at once. They self-regulate. The judge never has to break focus to show the timer.

Scenario: remote round, different cities

The judge is in Boston, the debater is in Seattle, on a video call. There's no physical timer to share. Screen-sharing the judge's phone is clunky and drops frames.

With browser sync, the debater just opens the room URL in a second tab or on a second monitor. Their countdown matches the judge's exactly. The video call stays dedicated to the round itself.

What you need to run two-device sync

Setup time, start to first speech: under 60 seconds. Zero accounts. Zero installs.

Try two-device sync in your next round

Free, no signup. Open on the judge's phone, share the QR code, done.

A quick FAQ

What happens if the WiFi drops mid-round?

Each device keeps its own timer running locally based on the last known start timestamp. When connectivity returns, devices re-sync silently. Short outages (under 30 seconds) are typically invisible to the debater.

Can more than two devices join a room?

Yes. You can have one controller and multiple displays — useful when you want a display visible to the debater, another to the opposing team, and maybe one for the room as a whole. DebateClock supports any number of read-only displays in a room.

Is the data private?

Rooms are ephemeral. There's no account, no history, no stored session data. When the last device leaves the room, the room is gone. The only data in transit is the current timer state.

Does the judge need to keep their phone unlocked?

Not necessarily, but the controller should stay awake during the round. DebateClock uses the browser's wake lock API on the controller to prevent the screen from timing out mid-speech. If the screen does lock, the timer keeps running and the debater's display stays accurate.