Sign shows offline

Symptom: the wall is displaying content correctly, but the dashboard shows the sign as Offline (gray indicator, #6b7280). Notifications may have fired suggesting the sign is down even though it visually looks healthy.

This is the most common false alarm in DisplaySync ops. The wall is right — the dashboard is right too, in the sense that it genuinely hasn't received heartbeats — but the kiosk is fine. Something in the path between kiosk and backend dropped the WebSocket. The fix is in the network, not the device.

Quick diagnostic

The dashboard transitions a sign to Offline after 15 seconds (3 missed heartbeats) — see Monitoring → Heartbeats. So if the dashboard is reporting offline:

1. Check the kiosk's Status Dashboard (Ctrl+Shift+S on the kiosk):
   • Connection Status: Connected — kiosk thinks it's online; the backend sees otherwise. Mismatch.
   • Connection Status: Disconnected / Reconnecting — kiosk knows it's offline; the network path is the issue.
2. Check the per-sign EventLog card on the sign detail page (collapsed by default). If many signs are flapping, this is a network or backend issue, not a per-sign problem.

Many signs are offline simultaneously

If multiple signs in the same event or venue all show offline at the same time, the issue is one of:

For backend / DisplaySync-side issues, there's nothing you can do at the kiosk level. Wait for service restoration.

One sign is offline

The vast majority of cases. Diagnostic path:

1. Confirm the wall is actually still up

Walk over and look at the wall. If it's showing the right content, the kiosk is doing its job. If the wall is blank or showing an error, this isn't a heartbeat issue — it's Content not loading.

2. From the kiosk, check the kiosk's view

If you can get keyboard or RDP access:

# Open the Status Dashboard
# Ctrl+Shift+S — look at "Connection Status"

# Or from PowerShell, check what the sign app sees
Get-Content "C:\ProgramData\DisplaySync\logs\sign.log" -Tail 100 |
  Select-String "WebSocket|heartbeat|disconnect|reconnect"

You're looking for one of three patterns:

• Recent successful heartbeats and no disconnect events — the kiosk thinks it's online and the backend can't see it. Move to step 3.
• WebSocket disconnected followed by repeated Attempting reconnection — the kiosk knows it's offline. Move to step 4.
• Constant connect/disconnect cycling — flaky network. Move to step 5.

3. Kiosk says connected, backend says offline

The kiosk's WebSocket session is alive, but heartbeats aren't reaching the backend (or aren't being processed in time). Possible causes:

A quick fix: from the dashboard, send a Refresh command. If the kiosk responds within 5 seconds, the WebSocket is bidirectionally working — what was probably wrong is now fixed (the WebSocket reconnected as part of receiving the command). The dashboard transitions to Online.

4. Kiosk says disconnected, can't reach backend

The kiosk knows it's offline. Common causes:

# Test from the kiosk:
Test-NetConnection api.displaysync.live -Port 443

# DNS resolution
Resolve-DnsName api.displaysync.live

# Outbound HTTPS
Invoke-WebRequest "https://api.displaysync.live/health" -UseBasicParsing

# Tail the live log during diagnosis (Ctrl-C to exit)
Get-Content "$env:ProgramData\DisplaySync\logs\sign.log" -Wait -Tail 20

Network failover

Wi-Fi ↔ Ethernet transitions can produce brief offline windows in the dashboard.

Diagnose:

• Network card on the dashboard shows currentInterface change at the transition (Ethernet → Wi-Fi or vice versa)
• The EventLog on the sign detail page shows a network_failover entry at the moment of transition
• The Network diagnostics overlay (Ctrl+Shift+N at the kiosk) shows the active NIC live

Fix paths:

• Both interfaces configured is the resilient path — the kiosk keeps a route up as long as either is reachable. Most modern thin clients handle this automatically.
• One interface is unreliable — disable it via Windows network preferences (netsh interface set interface "Wi-Fi" admin=disable) or at the venue switch port. Failover loops cost more uptime than a single stable interface.

5. Connect / disconnect flapping

Repeated WebSocket connected followed by WebSocket error followed by Attempting reconnection, in tight loops.

Cause is almost always network instability, not the kiosk:

• Wi-Fi roaming between APs — the kiosk hops APs and the WS drops on each hand-off
• Wi-Fi signal strength — kiosk is at the edge of an AP's range
• AP saturation — too many clients on the AP during a busy session
• Captive portal periodically re-prompting — some venue Wi-Fi systems force re-auth every N minutes

Fixes, in order of effectiveness:

1. Plug it into Ethernet. If you can run a cable, this fixes most flapping cases instantly. See Network resilience.
2. Move the AP closer, or reseat the kiosk out of an RF dead zone.
3. Pin the kiosk to a specific AP if your venue Wi-Fi supports band steering / AP pinning.
4. Add a portable AP on your own LTE link as a backup — see Hardware requirements → Network hardware.

False positives during transient issues

Heartbeat failures shorter than ~75 seconds (15 s offline threshold + 60 s notification deferral) don't trigger notifications. Quick blips show up in the audit log as offline-online transitions but don't wake anyone up. If you're seeing brief "offline" flashes in the dashboard with no notifications, that's normal venue-Wi-Fi behavior and not worth chasing.

If notifications are firing for blips that obviously aren't real outages, raise the deferral or unsubscribe from signOffline notifications for this event — see Notifications → Managing your preferences.

Dashboard refresh trick

Sometimes the dashboard's local view is stale even though the backend has correctly transitioned the sign to online. A hard browser refresh (Ctrl+Shift+R / Cmd+Shift+R) re-fetches state and resubscribes to the WebSocket.

If a hard refresh consistently changes the displayed state, your laptop's WebSocket subscription has gotten stuck — usually because the laptop slept and Chrome's WS reconnect didn't fire. Not a kiosk problem.

Still offline after working through this

Capture diagnostics per Getting support:

• Last 500 lines of sign.log from the kiosk
• Screenshot of the kiosk's Status Dashboard (Ctrl+Shift+S)
• Test-NetConnection api.displaysync.live -Port 443 output from the kiosk

Then reach out. The combination of those four artifacts is enough to triage almost any heartbeat-path issue.