Signage Readiness uses real player heartbeats, playback events, published revisions, and content hashes to show whether a location's screens are operating. It does not infer that a TV is healthy from a saved screen assignment alone.
Read the Opening readiness checks
Open Admin → KDS & Guest Displays → Signage Readiness. The opening checklist verifies six separate conditions: a published board, a configured hashed TV key, stable published screen assignments, reporting players, an online fleet, and at least one proof-of-play event in the last 24 hours.
The percentage is a summary of those checks. Review the failed check and its detail instead of treating the percentage as a guarantee that guests can see the correct menu.
Understand heartbeat and offline states
The Screen fleet table is based on each player's last accepted heartbeat. The operational thresholds are:
- Online: last heartbeat was less than 2 minutes ago.
- Warning: 2 minutes without a heartbeat.
- Breached: 10 minutes without a heartbeat.
- Critical: 30 minutes without a heartbeat.
Each row also shows the reported scene, published board revision, cache status and age, viewport, last-seen time, and recorded player error. A cached or offline playback event can prove that a scene played from local cache, but it does not prove the player could fetch the newest revision.
Export proof of play
Under Proof-of-play report, choose the last 24 hours, 7 days, or 30 days and optionally choose one screen. Select Download CSV. The export contains the screen ID, scene ID, board revision, start and end times, duration, and whether playback occurred offline.
The API accepts a positive range no longer than 31 days. An empty report means no accepted playback transitions matched that tenant, period, and screen filter; it is not evidence that the board was scheduled or visible.
Review publication history
Every successful publish creates an immutable publication entry with a revision, publication mode, timestamp, content hash, and actor audit. The current live revision cannot be rolled back to itself.
To restore an older board, find the intended entry under Immutable publication history and select Rollback as new revision. Confirm the action. Rollback republishes the stored snapshot as a new revision; it does not erase or rewrite the intervening history.
If the live revision changed after the page loaded, the rollback can be rejected by the revision conflict check. Refresh the page, confirm the newest history, and decide again instead of forcing the older snapshot over another administrator's work.
Verify recovery on physical screens
After a publish or rollback, refresh Signage Readiness and compare each player's reported revision with the latest publication. Open the physical screen and confirm the scene, prices, assets, emergency notice state, and schedule behavior. Wait for a complete scene transition when proof-of-play evidence is required.
Publication success and a new revision prove that the server accepted the board. They do not by themselves prove that every TV was powered on, online, or able to download it.