Why your fire alerts might never reach the screens you paid for
A screen that ignores fire alerts is not a failure of the hardware. It is a failure of the permissions it was granted, or the ones it was denied. When a device lacks the display over other apps permission, it cannot interrupt a loop. The screen remains silent even if the server sends an alert. This is not a bug. It is how Android enforces its own rules: without that permission, the system treats the app as a background player, not as an overlay.
The problem often starts with IT policies. Many estates segment their network to isolate operational systems from corporate traffic. A digital signage app on a VLAN with no internet access cannot poll the server. It plays its loop, unaware that a fire has been reported. The same happens if a screen is moved to a different subnet after installation. The device’s connection rules change, but its cached content does not. It carries on as if nothing has happened.
Offline mode is another trap. If a screen loses its connection, it falls back to cached content. That is useful for keeping displays running, but it does not help in a fire. Without a live check-in, the server has no way of knowing the screen is offline, let alone that it is stuck on an old message. The panel shows the alert as "sent", but the wall shows nothing. The responsible person sees compliance where there is none.
The worst case is when permissions are revoked after installation. Some MDMs or security tools strip display over other apps as part of a routine update. The screen still works for advertising or wayfinding, but it will not show an evacuation alert. No one notices until a drill reveals blank screens where warnings should be. By then, the fix is not just technical, it is procedural. The estate must retrain staff, re-audit permissions, and confirm that every screen can still interrupt its own content. Without that step, the system fails before the fire does.
The one fire safety duty digital signage cannot replace, and why it matters
Digital signage can show an evacuation alert within seconds, but it cannot confirm that every person has left the building. The 2005 Regulatory Reform (Fire Safety) Order requires a "suitable warning" to occupants, but it does not define suitability by screen visibility alone. A flashing message on a wall does not prove evacuation. Neither does a log of alerts sent. What the Order demands, and what no digital system replaces, is evidence that people have moved to safety.
The gap matters in two ways. First, a screen that displays an alert may still be showing it while the last person walks past. Second, even if the alert reaches every device, there is no way to tell whether anyone saw it. A screen in a stairwell might be obscured by smoke. A phone in a pocket could be on silent. A staff member in a meeting room might not glance up. None of these failures show up in a playback log.
The choice then becomes: rely on screens alone, or pair them with a system that can verify movement. The table below compares the two approaches for a medium-sized office with three floors and shared stairwells.
| Method | What it confirms | What it cannot confirm | Compliance risk if it fails |
|---|---|---|---|
| Digital signage only | Alerts were sent to screens | Whether anyone saw the alert | No record of evacuation beyond the message being displayed |
| Manual roll call | Staff account for their presence | Speed of response or missing occupants | Delayed evacuation if checks are slow or incomplete |
| Heat/pressure sensors | Zones are clear of people | Which individuals remain | False positives if sensors trigger without cause |
| Combined approach | Alerts sent and zones cleared | Exact headcount per floor | Reduced exposure if sensors back up screen coverage |
The Order does not ban screens. It requires a warning that is suitable for the risk. A silent screen in a fire is not suitable. A screen that shows an alert but offers no way to check if people left is also not suitable. The difference between the two is not in the hardware, but in what happens when the system is tested, and whether the responsible person can prove it worked.
How fast does an alert actually reach a screen, and what slows it down?
A fire alarm sounds. The delay between that trigger and an alert appearing on a screen is not a fixed number. It is a chain of steps, each with its own failure mode.
The first link is the network. A screen does not wait for the server to push an alert, it polls it instead. If the connection drops, the device uses its own cached content. When the link recovers, the screen checks for new messages. This is why a brief outage does not stop an alert, but a prolonged one does. A site with a single unreliable switch or a VPN that tunnels all traffic will see delays if that path fails. The screen only moves to the next alert when it confirms the server has nothing else to show.
The second link is the device itself. A screen granted the permission to overlay its display will interrupt whatever is playing. One that was not granted that permission, perhaps because the installer missed a step or the user revoked it, will ignore the alert entirely. This is not a setting buried in menus. It is a system-level permission that Android enforces. Without it, the screen behaves as if the alert never arrived.
The third link is the content. If the screen is set to play a loop during certain hours, it will do so unless the alert has higher priority. This is not a configuration error. It is how the system is designed: the loop runs until something forces it to stop. A fire alert does not force anything unless the device is set to treat it as an emergency override. If it is not, the loop continues while the alarm sounds in the background.
Finally, there is the device’s state. A screen with outdated software may not handle alerts the same way as one with the latest version. This is not a matter of performance. It is a change in how the system interprets commands. Three months after installation, a screen might still work, but it might no longer recognise the format of an alert designed for a newer build. The result is a blank screen or a frozen display, neither of which meets any requirement.
Each of these steps has a mechanism. The network drops, the permission is missing, the loop takes priority, or the software is out of date. The alert does not fail at random. It fails at a specific point in the chain, and that point is where the responsibility lies.
The second-order cost: when screens become a liability in fire investigations
When an investigation follows a fire, the responsible person’s statements about how alerts were delivered become evidence. If screens were supposed to show an evacuation message but did not, the explanation must be precise, and a vague answer creates doubt. A common failure is screens that look active but were playing a loop when the alert arrived. The system may have logged the alert as "sent", but the screen never interrupted what was already on display. Without a record of whether each device actually stopped its scheduled content, an inspector cannot trust that the alert reached anyone.
The problem is not just that screens missed the message. It is that the system cannot prove they did not. A fire marshal reviewing logs will see a timestamp for the alert, but no confirmation that every screen obeyed it. If the network failed during the alert, the cached content on each device kept playing. If a screen’s "display over other apps" permission had been revoked, perhaps by an automatic update or a well-meaning IT team, the alert vanished without trace. Either way, the responsible person must explain why the screens did not perform as intended, and without per-device confirmation, the explanation becomes a guess.
Insurance claims face the same risk. If a policy requires "visible warnings" as part of the premises’ safety measures, and those warnings were never visible on half the screens, the claim may be rejected. The insurer will ask: How do you know the alerts worked? A log of scheduled messages is not enough. What matters is whether each screen interrupted what it was showing, and whether it did so within seconds, not minutes. Without that proof, the burden shifts to the responsible person to demonstrate compliance through other means, which often means retrofitting manual checks or accepting that the digital system cannot be relied upon in an emergency.
The root cause is simple: the system’s own records assume success. It tracks what was sent, not what was seen. When a screen fails to interrupt its loop, the failure is silent. No alarm sounds. No log entry marks the event. By the time an inspector or investigator asks what happened, the only answer is we do not know, and that answer is not enough.
Overlay permission is what breaks first, and no one notices until it’s too late
A screen that ignores fire alerts is not a failure of the system, it is a failure of permission. Every digital signage platform relies on Android’s display over other apps setting. Without it, an alert cannot interrupt scheduled content, even if the software is installed and the network is working. The problem is silent. No error message appears. The screen carries on playing its loop, and the responsible person has no way of knowing the overlay has been disabled, until an inspection or, worse, an incident.
This happens in two common ways. The first is during routine maintenance. IT teams often reset devices to default settings to apply updates or enforce security policies. A factory reset wipes display over other apps along with every other permission. The screen restarts, the default content resumes, and the fire alert system remains dormant. The responsible person may not realise the overlay was ever active, let alone that it has been removed.
The second risk is policy drift. Some organisations block system-level permissions by default, treating them as a security vulnerability. If display over other apps is disabled in the device management console, or if a well-meaning administrator revokes it during a permissions audit, the screens become compliant with IT policy but useless for fire safety. The alert software logs no errors. The screen does not flash a warning. There is nothing to alert the responsible person that the critical function has been lost.
An audit catches this before it matters. Check each screen’s permission settings manually or via a management tool. Look for devices that have not received an alert in the past week, those are the ones that have silently failed. Test the overlay by sending a dummy alert and confirming it interrupts content. If it does not, the permission is missing. The fix is straightforward: re-enable display over other apps and document the change. The harder part is ensuring this check is part of the regular maintenance cycle, not an afterthought.
What happens three months after installation that makes your screens non-compliant?
A fire safety system’s compliance does not last. Three months after installation, screens that once displayed evacuation routes or emergency contacts may no longer do so reliably. The issue is not hardware failure, it is the silent drift of information.
Consider the emergency contact list. A compliance officer signs off on a screen showing the correct phone numbers for the fire brigade, site manager and first aider. But when the site manager leaves and no one updates the display, the screen still shows their old extension. A visitor or member of staff follows the instructions, dials the number, and reaches a disconnected line. The screen has not failed; the data it shows has become obsolete.
Software updates compound the problem. A screen’s operating system or signage app may receive a patch that fixes a bug or closes a security hole. If the update is ignored, the screen might stop acknowledging alerts entirely. The responsible person checks the system once a year and sees no red flags, but the screen no longer reports its status because the update broke its connection to the server. The panel still shows content, but it no longer confirms whether it is working.
Battery tests in backup power supplies are another weak point. A screen’s UPS is tested during installation and passes. Three months later, the test log is filed away and forgotten. When the power fails, the screen’s battery lasts only half as long as it should. Staff evacuate, but the emergency information remains visible for critical minutes longer than planned because the backup was never verified.
The responsible person cannot see these failures unless they check. A screen that displays content does not prove it is compliant. The drift happens in the gaps between inspections, when lists are not reviewed, updates are postponed, or tests are overlooked. By then, the system is no longer what it was installed to be.
The responsible person’s checklist: where to audit, and what to fix before the next inspection
The 2005 Regulatory Reform (Fire Safety) Order and the 2021 Fire Safety Act require fire safety information to reach everyone in a building immediately, but digital signage often fails this test in ways that go unnoticed until an inspection. The responsible person’s audit should start with the screens themselves, not the software or the network. A screen that cannot interrupt what is playing, even if it is displaying a corporate video loop, is not compliant, no matter how fast the alert arrives. Check each device for the Android permission that lets an alert break through. A screen missing this permission will play its scheduled content until manually reset, leaving staff unaware of an evacuation.
Next, verify that every screen reports what it received. A panel that only shows scheduled content does not prove compliance. The system must log which screens acknowledged an alert and which did not. If a screen in a basement or a remote wing fails to respond, the panel must flag it before the next inspection. This is not optional, it is how you prove the system works under real conditions.
Hidden dependencies often break compliance without warning. A screen that relies on a network connection for anything other than updates is a risk. If the Wi-Fi drops, the screen should continue playing the last cached alert, not revert to a loop or a blank screen. Test this by disconnecting a single device for eight hours. If it stops showing alerts, the system is not compliant.
Finally, check the content of the alerts. A generic "evacuate" message is not enough. The 2021 Act requires clear instructions tailored to the building’s layout, routes, assembly points, and roles. If the digital signage cannot display custom text or images for different floors or departments, it is not fit for purpose. Pre-built templates are useless if they cannot be adapted to a real fire scenario.
Start with the devices that cannot interrupt content, they are the first to fail. Then move to the ones that do not report back. Fix the network dependency next. Only then can you trust the system meets the law. If any step fails, the responsible person has not discharged their duty. The next action is simple: identify the non-compliant screens, remove their permission to play loops, and ensure they log every alert they receive. Do this before the inspection arrives.
