Log locations

When something is broken, your first move is "look at the logs." This page is the index — what lives where, on which platform, and how to grab it.

Desktop sign — Windows

The kiosk app writes its main log to:

C:\ProgramData\DisplaySync\logs\sign.log

A companion error.log rotates alongside it. The data root is machine-wide (writable by all users by default), so the path doesn't depend on which kiosk user is logged in. For the complete map of what lives under that data root, see File locations.

error.log is the ERROR-level companion — same 5 MB rotation as sign.log, same 5-archive cap, but only ERROR-level lines are written. Pre-filtered = faster triage when something's gone wrong; this is the file to open first.

Tail from PowerShell (any session, with read access):

Get-Content "C:\ProgramData\DisplaySync\logs\sign.log" -Tail 100 -Wait

Canonical live-tail pattern (cross-referenced from sign-shows-offline, sign-wont-claim, kiosk-wont-start):

Get-Content "$env:ProgramData\DisplaySync\logs\sign.log" -Wait -Tail 20

The $env:ProgramData form is preferred over the literal C:\ProgramData\ — it works across non-default install drives.

Rotation: the kiosk app rotates sign.log once it hits 5 MB; older files are archived as sign.log.1, sign.log.2, etc. By default, 5 archives are kept.

Desktop sign — Linux

/var/lib/displaysync/logs/sign.log

Same rotation rules. Tail:

tail -F /var/lib/displaysync/logs/sign.log

Desktop sign — config files

Adjacent to logs:

Fetch logs from the dashboard

The fastest way to get a kiosk's sign.log without RDP'ing in:

1. Dashboard → Sign detail → Remote control → Fetch logs
2. The kiosk responds within ~5-15 s with a log bundle (most recent + rotated archives)
3. The bundle appears under the Logs card on the same page
4. View inline, copy, or download as .zip

This works whenever the kiosk is online. See Remote control → Fetch logs.

Scope: Fetch Logs tails the last 500 lines of sign.log only. It does NOT include error.log or rotated archives (sign.log.1 etc.). Operators needing the error-only stream check the kiosk locally via Ctrl+Shift+C → "Open data folder," or pull a full bundle via the USB recovery script's diagnostic mode. For an end-to-end forensic capture from an offline kiosk, see the Quick reference PowerShell snippet at the bottom of this page.

On-kiosk Status Dashboard

For real-time inspection without leaving logs around: press Ctrl+Shift+S on the kiosk to open the Status Dashboard overlay:

• Connection status, last heartbeat, last command
• Sign ID, short code, MAC
• Backend URL, WebSocket URL, IP, Tailscale IP
• Cache items count and size
• Recent error counts

Press Esc to dismiss. Useful for a quick "is this device healthy?" check without grepping the file.

Windows Event Viewer

OS-level events live in Windows Event Viewer. Two logs are worth checking when the sign app or its scheduled task is misbehaving:

From PowerShell, the Task Scheduler log is the single most useful for "did the kiosk restart properly":

Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -MaxEvents 50 |
  Where-Object { $_.Message -match "DisplaySync" } |
  Format-Table TimeCreated, Id, Message -Wrap

Tailscale logs

Windows:

C:\ProgramData\Tailscale\Logs\tailscaled.log

Or via Tailscale's CLI:

& "C:\Program Files\Tailscale\tailscale.exe" debug daemon-logs

Linux:

journalctl -u tailscaled

Useful for diagnosing connection-state issues — see Tailscale issues.

Sentry (backend visibility)

Errors from the desktop sign app, the dashboard, and the backend itself stream into Sentry. If you have access to the org's Sentry project:

• Desktop sign errors show up tagged with the sign's sign.id; the signId, organizationId, and eventId are attached as Sentry context (in the sign context object), not tags
• Dashboard errors include the user's email and the route they were on
• Backend errors include the request URL and (for sign-related errors) the relevant signId

Sentry catches things logs sometimes miss — async errors, unhandled promise rejections, errors before the log file is even open.

Search syntax in the Sentry UI: context fields are accessed via dot-prefix.

sign.signId:"abc-123"
sign.organizationId:"def-456"
sign.eventId:"ghi-789"

Top-level tags (without the sign. context prefix):

appVersion:1.3.1
environment:production
sign.id:abc-123

Note the asymmetry: sign.id (with a literal dot in the tag name) is a tag; sign.signId / sign.organizationId / sign.eventId are context fields under the sign namespace. Both use the same query syntax in the UI, but they're separate fields under the hood — if a search returns no results, you may have the wrong one.

If you don't have direct Sentry access but think a Sentry event explains your issue, mention it in your support request — we can correlate by timestamp + signId.

Backend logs (DisplaySync internal)

Backend logs are not directly exposed to customers. If you need backend-side diagnostics for a specific incident — for example, "did my claim request reach the server at 14:03 UTC" — include the timestamp and signId in your support request and we can look from our side.

Quick reference

For the most common case ("grab everything you'd want for a support ticket"):

# Make a folder
$out = "$env:USERPROFILE\Desktop\sign-logs-$(Get-Date -Format 'yyyyMMdd-HHmm')"
New-Item -ItemType Directory -Path $out

# Copy the sign logs
Copy-Item "C:\ProgramData\DisplaySync\logs\*" $out

# Copy config and database
Copy-Item "C:\ProgramData\DisplaySync\sign-config.json" $out
Copy-Item "C:\ProgramData\DisplaySync\database\sign.db" $out -ErrorAction SilentlyContinue

# Copy .env (sanitize before sending — may contain backend URL)
Copy-Item "C:\Program Files\DisplaySync Sign\resources\.env" $out

# Save the Status Dashboard view (manual step)
# Press Ctrl+Shift+S, screenshot, save to $out

# Recent Windows events
Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -MaxEvents 100 |
  Where-Object { $_.Message -match "DisplaySync" } |
  Export-Csv "$out\task-scheduler-events.csv" -NoTypeInformation

# Zip it up
Compress-Archive -Path "$out\*" -DestinationPath "$out.zip"
Write-Host "Bundle ready: $out.zip"

This is roughly what the dashboard's Fetch logs command produces, plus Windows-specific diagnostics. Useful when the sign is offline and you can't fetch remotely.