Your screens go dark at 3am, who fixes it when the cloud won’t?
When a screen fails in a cloud-hosted system, the provider’s dashboard flags the issue and escalates it to their team. The outage is logged, prioritised, and, if the contract includes it, fixed before the next working day. The facilities manager sees a ticket number, not a blank display. The problem is someone else’s to chase.
A self-hosted system does not work like that. If the server crashes, the screens stop receiving updates. They do not know they are supposed to check in. Without a heartbeat, the panel shows nothing. The first sign of trouble is when a member of staff walks past a dark screen at 7am and realises it has been off all night. By then, the server may have been down for hours.
The failure does not even need to be the server. A misconfigured firewall, a forgotten firmware update on the screens themselves, or a single device left on an old network, any of these can break the connection. The system relies on every screen polling the server at the same interval. If one device’s clock drifts by even a few minutes, it misses its next check-in. The panel marks it as offline. No one notices until someone walks past.
Worse, the problem spreads. If the server is unreachable, no screen updates its cached content. An alert meant for one floor fails to reach any screen until the network is restored. The cascade starts with a single device, but the impact is estate-wide. The facilities manager’s phone rings at 8am. The boardroom discussion begins at 9am. The invoice for the emergency IT contractor arrives at the end of the month.
Data residency isn’t just about GDPR, it’s about who owns your screens’ logs when a breach happens
When a hospital ward screen shows a patient’s name, next-of-kin details or a staff rota, that data does not belong in a third-party log. If a ransomware attack encrypts a cloud provider’s servers, the screens themselves become evidence, or a liability. Self-hosted signage avoids this by storing only what the screen needs to display, and nothing more. The server does not log content; it sends instructions, and each device reports back only what it has shown. That means an auditor can trace which alerts reached which screens, but no one outside the building ever sees the raw data.
The trade-off is visibility. A cloud system might offer a dashboard showing every screen’s activity, but that dashboard lives on someone else’s infrastructure. If that system is breached, the provider’s terms of service decide who owns the logs, and whether they can be used in an investigation. Self-hosted signage flips this. The logs stay on-premise, under the same access controls as the rest of the network. When a breach happens, the IT team knows exactly what was exposed: only the alerts that were sent, not the underlying data that triggered them.
Here’s the difference in practice:
| Scenario | Self-hosted signage | Cloud-hosted signage |
|---|---|---|
| Data stored on screens | Only the alert content, cached locally | Full activity logs, uploaded centrally |
| Access to logs | Controlled by the site’s IT policy | Subject to the provider’s data policies |
| Ransomware attack | Logs remain readable on local servers | Logs may be encrypted or held for ransom |
| Audit trail | Traceable to the device’s heartbeat | Depends on third-party retention rules |
| Compliance questions | Answered by the site’s own records | Answered by the provider’s SLA |
The risk is not hypothetical. A leaked staff schedule in a cloud log could violate GDPR if it includes personal details. A lost patient flow record might breach clinical confidentiality. Self-hosted signage does not prevent mistakes, it ensures they stay within the organisation’s control. The alternative is trusting that a breach will never happen, or that a third party will handle it better than the team already managing the estate. Neither is a safe bet when seconds matter.
Per-screen licensing sounds cheap until you multiply by 500 screens
Per-screen pricing for digital signage often looks cost-effective when starting small. A single screen or a handful of displays can be managed without much thought. But that model breaks down when the estate grows.
Hardware failures are common for commercial displays. That means some screens will fail in any given year. On a small number of devices, this is easy to manage. At scale, though, the same failure rate becomes a significant number of devices to replace. Each replacement requires a site visit, a new license, and downtime while the old player is removed and the new one configured. The per-screen fee may be modest, but the cumulative cost of managing failures at scale is not.
Then there’s the time spent troubleshooting. A player that refuses to load content, or one that crashes when an alert is sent, can halt an entire display network. With per-screen licensing, each affected device needs its own diagnosis. Is it a corrupted cache? A permission issue? A conflict with another app? The fix might require a reboot, a factory reset, or even a hardware swap. At a small scale, this is an occasional annoyance. At scale, it becomes a weekly distraction for the IT team.
Finally, scaling from a small deployment to a large one exposes another hidden cost. A self-hosted system licensed per screen often assumes a fixed number of displays. Adding hundreds more means renegotiating the license, adjusting the server capacity, and recalibrating the network. The upfront savings per screen vanish when the total bill balloons, and when the IT team is pulled away from other priorities to manage the expansion.
The per-screen model works for small deployments. For anything larger, the real cost isn’t the software. It’s the time, the failures, and the unplanned work that follow.
Offline behaviour: Why your ‘always-on’ signage cuts out when the WiFi does, and how long it stays dead
A screen that loses its connection does not stop working. Instead, it switches to the content it cached last time it polled the server. That content remains playable even when the network is down, and the screen continues to show it until the next scheduled update, or until the cache itself fails.
The cache is not a backup of every possible message. It holds only the most recent version of each playlist and scheduled item. If the network stays down for more than 72 hours, the local database on the screen marks those items as stale. When the connection returns, the screen requests a full refresh. Until then, it shows whatever it has, even if it is outdated.
This is where the trade-off appears. A cached message is better than nothing, but it is not the same as nothing. In a factory, a shift board might still display yesterday’s start times. In a hospital, a waiting room screen could show an old appointment list. The screen itself does not know the difference. It only knows that its local copy is no longer fresh.
Emergency alerts are different. They do not rely on the cache. Instead, they use Android’s display over other apps permission to interrupt whatever is playing. If the screen has that permission, and it must, to show alerts at all, it will display an emergency message even without a network. But if the local database was not synced before the outage, the screen will not know which alerts to show. It will wait until the connection returns to check the server, and until then, it will show nothing.
The panel shows this clearly. A screen with a stale cache appears greyed out. A screen waiting for an unsynced alert shows a warning. Neither is a silent failure. The system does not pretend the content is up to date. It tells you exactly what the screen is showing, and whether it is showing it because it has to or because it should. The choice then is yours: whether to accept the delay, or to ensure the network stays up.
The three-month rule: What breaks after the warranty expires and before you notice
A screen that flickers during an alert has lost its power supply, not its mind. The unit itself may still be under warranty, but the PSU that failed is not. Three months after installation, the manufacturer’s support ends for the firmware that drives the display. The next Android update, pushed automatically by Google, brings a new driver that conflicts with the signage app’s overlay permission. Now the screen either ignores alerts entirely or cycles between a black frame and a corrupted preview.
Cloud systems often mask this by running their own version of the player, patched to ignore driver changes. They also hide the root cause: the PSU’s degradation was never logged, because the cloud provider’s dashboard only tracks what it controls. A self-hosted system, by contrast, records every heartbeat. When a screen stops acknowledging alerts, the panel shows exactly which device has failed, and whether it’s the hardware or the connection.
Software updates compound the problem. A cloud service may roll out a new player version silently, but if it drops support for older TV models, those screens go dark until IT reinstalls the legacy app. Self-hosted signage avoids this by running on the customer’s server, where updates are scheduled, not forced. The trade-off is visibility. A flickering display in a cloud setup might just be another “minor incident” logged by an outsourced team. In a self-hosted system, it becomes a clear failure: the PSU, the driver, or the screen itself. The invoice doesn’t show which one you’ll be replacing.
You’re not just hosting signage, you’re inheriting someone else’s support tickets
When a self-hosted signage system fails, the first call does not go to a vendor. It goes to the person who manages the server, the network or the screens, often someone who did not ask for this responsibility. The failure might be a single screen stuck on an old alert, or a batch of devices that never received an update because the polling loop crashed. Either way, the explanation begins with a choice: whether to describe the problem in technical terms or to translate it into something the estate manager can act on.
The translation is the hidden cost. A facilities manager asks why the fire drill announcement did not appear on the ground-floor screens. The answer, the Android service that handles overlays was killed by a background process, means nothing to them. Instead, you walk them to the screen, show them the cached content still playing, and confirm that the alert did reach the device. Then you explain that the screen ignored it because the permission to interrupt playback had been revoked during a routine update. This is not a bug in the signage software. It is a conflict between two apps, neither of which told anyone it had happened.
Worse, the fix depends on knowing which screens were updated last. If the estate runs a mix of Android versions, some on 11, others on 13, each may handle the overlay permission differently. A screen updated six months ago might still work, while one patched yesterday could drop alerts entirely. There is no central log of this. You must check each device, grant the permission manually, and hope the next OS update does not undo it. The vendor’s documentation does not cover this. Their support team cannot access the screens. The ticket stays open until someone on-site resolves it.
The real invoice does not list these hours. It does not charge for the time spent reassuring a manager that the system can work, if only the screens were all the same model and the staff remembered to test the permissions after every patch. That work falls to whoever inherited the system, not the supplier. And when the next failure happens, perhaps a corrupted cache that silences all alerts until a reboot, the same questions start again.
Cloud signage isn’t foolproof, but self-hosted risks turn ‘minor incidents’ into ‘boardroom discussions’
A cloud service might slow to a crawl during a peak, or drop a few alerts in a storm, but those are minor incidents. A self-hosted system fails in ways that force unplanned budget reallocations or PR crises because the damage is immediate, visible, and, once it happens, hard to undo.
Take a corrupted database. A cloud provider might back up every version of your content, but a self-hosted server with no redundancy wipes everything when the drive fails. That’s not a few screens showing yesterday’s menu; it’s every location’s playlists, schedules, and emergency templates gone. The cost isn’t just restoring the data, it’s the lost revenue from incorrect pricing, the compliance risk from missing legal notices, and the boardroom explaining why staff couldn’t see a critical safety alert. A cloud outage might inconvenience; a local failure rewrites the incident report.
Then there’s the support cost. A cloud provider’s helpdesk can blame a third-party API or a misconfigured firewall. Your own server? The person fixing it is the one who also handles payroll or active directory. When the WiFi drops, a cloud system might queue alerts until the connection returns. A self-hosted screen with cached content keeps running, but if the server itself is unreachable, no one knows which displays are dead until a manager walks the estate. The panel that tracks screen status is only as reliable as the network it depends on.
The trade-off isn’t just uptime. It’s visibility. A cloud provider can obscure failures behind vague status pages. Your own system makes them undeniable. That’s why the invoice doesn’t show the real cost: not the licence fee, but the emergency meeting after the screens blanked during a fire drill, or the extra shift paid to manually update every display when the database locked.
If you’re running signage on your own server, the next step is to check whether every screen can still draw over another app. The panel flags screens that cannot cover another app before you need them. Without that, the first alert that fails isn’t a glitch, it’s a gap in your resilience. Test it now.
