Getting support

You've worked through the symptom-indexed troubleshooting pages and the issue isn't resolved. Time to ask for help.

This page is about how to ask in a way that gets a fast, useful answer — what to capture, how to describe what you've tried, and where to send it depending on the urgency.

Check release notes first

If a problem started after a known update, the release notes may already document it:

• Desktop sign release notes — runs on the kiosk
• Web dashboard release notes — what you see in the browser
• Mobile app release notes — TestFlight / Google Play

For now, release notes are sparse — most known issues won't be there yet. As the product matures, this is the first place to check.

The minimum useful report

A support request without enough context turns into a back-and-forth that wastes the worst hour of a live event. The five fields below cover almost every triage path:

Get those five and we can usually triage within the first reply.

Useful artifacts

Beyond the five fields above, attach as much of the following as you have:

• Last 500 lines of sign.log from the kiosk — see Log locations. The dashboard's Fetch logs command makes this easy if the sign is online.
• Screenshot of the kiosk's Status Dashboard (Ctrl+Shift+S). Takes 2 seconds and shows us 80% of the kiosk's local state.
• Screenshot of the dashboard's view of the affected sign — sign detail page, with the Health and Status cards visible.
• Phone photo of the wall if the symptom is visual (blank, frozen, wrong content).
• Output of the smoke tests from Network requirements → Auditing connectivity if you suspect a network issue.
• error.log (ERROR-level companion to sign.log; same directory) — pre-filtered for faster triage. See File locations.
• EventLog screenshot from the sign detail's AnalyticsTab — shows the watchdog events (frame_anomaly, page_frozen, process_crash) if any fired.
• GPU info from dxdiag /t dxdiag.txt on the kiosk — useful if the symptom involves the renderer.
• Multi-instance count — Get-Process -Name "DisplaySync Sign" | Measure-Object. >1 indicates an orphan from a prior crash.
• requestId from the failed claim attempt (post-handshake fleets). Surfaces in the dashboard error toast and the kiosk's error.log.

For a fully bundled diagnostic snapshot, the script at the end of Log locations packages the most-asked-for artifacts in one zip.

What you've already tried

Tell us what you've already done and what happened. Saves us walking you through steps you've covered.

A good "tried" section looks like:

Worked through Sign shows offline. The kiosk's Status Dashboard shows Connected, but the dashboard side is offline. Test-NetConnection api.displaysync.live -Port 443 from the kiosk succeeds. Refresh from the dashboard does NOT bring the sign back online — the command stays Pending. Reboot device fixes it temporarily but the sign goes offline again within ~5 minutes.

Concrete, sequential, includes both what worked and what didn't. Saves an hour of back-and-forth.

Dashboard says "command sent" but nothing happens

Symptom: you click Reboot / Reboot Device / Check for Updates / Fetch Logs in the dashboard. UI confirms the send. Kiosk silently ignores it.

Cause: kiosk clock has drifted more than ~30 seconds from real time. Reboot, Reboot Device, Update, and Fetch Logs are all time-validated at the kiosk and silently dropped if the clock is too far off. The Refresh command isn't time-validated, so if Refresh works but those four don't, that's the clock-drift signature.

Diagnose on the kiosk:

w32tm /query /status
w32tm /resync   # if drift detected

If w32tm /query /status reports a Last Successful Sync more than a few hours ago, NTP isn't keeping up. Common causes:

• Venue firewall blocks UDP/123 (NTP) — see Network ports → DHCP / DNS / NTP
• time.windows.com is unreachable from the venue — switch to pool.ntp.org or a venue-provided server
• BIOS clock is wrong and Windows hasn't corrected yet (boot too recent) — reboot and wait

Smoke-test the backend from the venue laptop

GET https://api.displaysync.live/health returns a JSON object with subsystem flags — DB up/down, Redis up/down, memory, env, version. A customer or tech with venue laptop access can hit this directly to confirm "is the backend even up right now?" before assuming the bug is on their end.

curl https://api.displaysync.live/health

200 OK + JSON with status: "healthy" and all subsystems green = backend is fine; problem is venue-network-side or kiosk-side. 503 = backend is having a real outage; check the status page.

See API overview → Health endpoints for the other two endpoints (/health/ready and /health/live) and their use in orchestration probes.

Where to send it

Live event — drop everything urgent

If a sign is broken in front of an audience and you need help right now:

• Email: [email protected]
• Subject: start with [URGENT - LIVE EVENT] so it routes to the on-call rotation
• Body: the five-field minimum from above, plus what you've already tried. Don't perfect it — speed matters more than completeness, and you can follow up with artifacts.

We'll respond within 30 minutes during US business hours, within ~1 hour overnight. If you don't hear back in 30 minutes, escalate via your account manager's direct line (Enterprise/Managed tiers).

Standard support

Non-urgent issues, post-event triage, "this happened, want to understand why":

• Email: [email protected]
• Subject: describe the symptom plainly — "Sign LOBBY-WEST-03 went offline at 14:03 UTC, can't reproduce locally"
• Body: the five-field minimum + artifacts

Response within 1 business day. We'll often do a longer write-up if the issue suggests a docs gap or a product fix.

Bug reports

If you think you've found a product bug (not a configuration or environment issue), the same email path works. Include:

• The smallest reproducer you can manage — exact steps to reproduce
• Expected vs. actual behavior
• Environment: desktop sign version, dashboard version, browser if relevant

We don't ship a public issue tracker; bugs come back to you with a fix or a workaround in the support thread.

Feature requests

[email protected]. We read all of these. We don't promise individual responses, but we triage everything and reach back out when something we've shipped covers a request you sent in.

During a live event — escalation tips

A few things that make support faster when you're under pressure:

• Use the dashboard's Fetch logs command before rebooting. Reboots destroy the in-memory state that makes logs informative.
• Capture the phone photo first. A "what does it look like right now?" photo is the single highest-information artifact for visual issues.
• Don't reboot, then ask, then reboot again. Pick one path. If you've already tried a reboot, tell us — and don't reboot again until we've replied with a hypothesis.
• Note the exact timestamp the issue started, in UTC if possible. Our backend logs are in UTC; aligning saves us 5 minutes of guessing.

Incident communication

Service-wide issues (backend down, dashboard slow, real-time updates lagging) are communicated by email to org owners and admins. A standalone status page at status.displaysync.live is on the roadmap and will be linked here when it ships.

Until then: if you suspect a backend incident before opening a ticket, email [email protected] with [STATUS CHECK] in the subject. We'll confirm whether something is on fire on our side and skip the full triage cycle if so.

Hours and tiers

See Pricing tiers for the full tier breakdown.

What we ask in return

A few practices that make the support relationship work for both sides:

• Don't share secrets. When sharing logs, sanitize backend URLs that contain credentials, auth headers, or anything else sensitive. Tail-IPs, sign IDs, and org names are fine to share with us; bearer tokens are not.
• Test in staging first for non-urgent changes. We have a staging environment at staging.displaysync.live that mirrors production behavior — easier to break safely than a live event.
• Send the fix back. If you figured out a workaround we missed, drop us a note. We'll add it to the docs (with credit if you want it) so the next person doesn't hit the same wall.