Troubleshooting
This section is indexed by symptom, not subsystem. When something is wrong on a show floor, you don't search for "WebSocket reconnection logic" — you search for "sign shows offline." Pick the symptom that matches what you see and follow it down.
If none of these match, see Getting Support for what to capture and where to send it.
Always capture before you reboot
Before rebooting a misbehaving sign, fetch its logs from the dashboard (Remote Control → Fetch Logs). A reboot that fixes the symptom also destroys the evidence.
Diagnostic toolkit
Three keyboard shortcuts let a tech with kiosk access pull live diagnostics without the dashboard:
Ctrl+Shift+S— Status overlay (sign ID, backend URL, connection state)Ctrl+Shift+N— Network diagnostics (live latency, reachability)Ctrl+Shift+C— Config overlay (URL override, exit for maintenance)
See Hotkeys for the full set.
Recognize before debugging
Before opening a triage path, two checks:
- Is the sign in monitoring mode? A monitoring-mode sign shows online but the wall is intentionally dark. The dashboard surfaces a "Monitoring" badge.
- Did the sign just auto-recover from a watchdog event? Signs reload themselves on white-frame, frozen-JS, or renderer-crash events. See Content not loading → The wall flashed and reloaded itself.
Recognizing these before debugging avoids chasing non-problems.
Stuck on QR after handshake retry
If a sign keeps cycling between handshake attempts and the QR screen — the dashboard reports device_load_failed or device_no_ack repeatedly — see Sign won't claim and Claiming signs → How a claim is committed.