Read Activity reports

Open Activity in Studio to see what Tilecast can confirm about the fleet and what changed over time. Choose a date range for historical reports; the current fleet and active incident counts describe the present, regardless of that range.

Choose a report

Tilecast records the first authenticated Player contact as one connection event, even when its HTTP and WebSocket reports arrive together.

Tab	Use it to
Overview	See current fleet health, active incidents, and summaries for the selected period.
Proof of Play	See sessions the Player reported as displayed, and how each session ended.
Incidents	Follow a continuing screen or content problem through recovery or manual resolution.
Content Health	Find Data Sources that stopped refreshing and assigned playlists with nothing available to play.
Screen Events	Inspect the technical events reported by Players. This tab is available to Owners and Administrators.
Audit Log	See changes made by Studio users. Editors see content-related activity; Owners and Administrators can see the full log.

Owners and Administrators can inspect Screen Events and diagnostic telemetry, export Proof of Play or Audit Log reports to CSV, and change Activity retention under Settings > Data retention. Editors can read content-related Audit Log entries. Overview, Proof of Play, Incidents, and Content Health reports are available to signed-in Studio users.

Interpret playback numbers

Proof of Play comes from reports sent by Tilecast Player. An assignment or schedule says what Tilecast expected to play; it does not prove that the Player displayed it. A playback record confirms the Player reported that presentation or content as playing. It cannot tell you whether anyone in the room saw or read the display.

For a screen using a multi-zone Layout, confirmed screen playback counts wall-clock screen time once even when several zones play at the same time. Content exposure adds the time of each zone’s content, so it can exceed the time the screen was on. These answer different questions and should not be added together.

Session completion rate describes how playback sessions ended. It is not a measure of whether scheduled content played. For that, use Playback compliance, which compares Player-confirmed screen time with expected windows Tilecast recorded when a selection became effective. Takeover time and intentionally cancelled windows are reported separately and excluded from the percentage. If there is no measurable expected time, Studio shows No data, not 0%.

A short network outage does not end a playback session when the Player reconnects. If a screen stops reporting for more than three minutes, Tilecast closes the session at the last confirmed heartbeat and records the gap as unknown. See the Activity event contract for the exact derivation rules.

Proof of Play lists a session only when the content was on screen long enough to count as a play: at least one second. A Player that restarts the same item over and over, or reads an item with no duration as “zero seconds”, would otherwise fill the report with plays nobody saw. Tilecast keeps the Player’s raw events under Screen Events so you can still see that it happened, but it doesn’t count them as plays. A play that failed is always listed, however short it was. If you see a screen whose Screen Events fill with item starts and completions a fraction of a second apart, update its Player and check the playlist item’s duration.

Expected windows are not reconstructed from today’s schedules. Compliance has no historical expectation for periods before Tilecast began recording those windows.

Diagnostic telemetry follows the same evidence rule. A measurement a Player does not report is unknown, not zero. For example, a Player that cannot measure frame luminance is not treated as a black screen, and a platform without one telemetry gauge does not silently contribute a zero to fleet results. Use the Player’s reported fields and incidents together rather than comparing missing gauges as if every platform measured the same thing.

Follow an incident

Content Health lists stale Data Sources, including sources that no Widget uses. A stale source opens a content incident only when a Widget uses it. That check includes nested Data Source selections and sources owned by an App. IDs written in an ordinary text field do not establish a dependency. Deleted Widgets and deleted sources do not create new stale-source incidents.

An incident represents a continuing condition, not every repeated error. Tilecast updates the same incident while the condition continues. When the condition ends on its own, it is marked recovered and remains in the report as history; it does not stay in the active list. A person can resolve an active incident, which is recorded separately from automatic recovery.

A playback incident recovers on its own when the content that failed plays through to a normal end again. A different item playing fine on the same screen doesn’t close it. If the same condition returns after an incident recovered, Tilecast opens a new incident instead of merging two separate outages into one.

Tilecast states a probable cause only when the evidence establishes one. A renderer failure can name its reported reason. A heartbeat gap proves only that reporting stopped, so an incident can correctly show an unknown cause instead of guessing whether power, Wi-Fi, or the device failed.

Owners and Administrators can acknowledge, assign, add a note, resolve, ignore, and reopen incidents. Other roles can read incidents. Use Understand a screen’s status to separate connectivity from playback health.

For exact metric and event definitions, see the repository’s Activity definitions and Activity event contract.