A screen is either showing what you published or it is not, and the difference is usually invisible until somebody complains. Monitoring exists to make that difference visible without turning every screen into a telemetry firehose.
The cost of asking too often
Screens run on modest hardware over shared connections. The more a status report asks of the device, the more it competes with the video it is supposed to be playing, so the useful signals are the cheap ones: whether the screen is online and when it last checked in, which manifest version it is actually running, whether it is on its schedule or on the fallback playlist, and whether its storage is filling up.
Current media, app version, screen resolution, and video-wall drift are reported the same way. None of that requires sampling a frame rate, which is the kind of measurement that costs more than the problem it detects.
Batching reports, aggregating the view
One check-in does two jobs: it reports the screen's state and asks whether anything new is waiting for it. The answer can carry a pending command — restart, clear the cache, check for an update — which the screen executes and acknowledges, so an operator can act on a screen without being on site.
Playback records follow the same logic. One entry per slide would be hundreds of writes for a screen that runs all day, so the player buffers what it played and flushes it in batches, recording spans rather than a stream of events.
On the workspace side the useful view is aggregated: plays per day, uptime per screen, which playlists actually ran, and which screens went quiet and for how long. The individual records stay available as history; they are just not what an operator needs on a dashboard.