9 Sep 2026

Uptime and ad continuity: keeping in-room screens alive on hotel Wi-Fi

In-room screen revenue does not die because the ads are bad. It dies because the screen is showing a spinning loader. The uptime playbook for operators running screens on guest networks.

The uncomfortable arithmetic of in-room screen monetisation is that uptime multiplies everything else. If your screens are functional 95 percent of the time, that sounds excellent until you realise you are forfeiting one night in twenty, and the nights you lose are not randomly distributed. Network problems cluster at peak occupancy, exactly when guests, their laptops and their streaming are hammering the same access points your screens depend on. A revenue model built on five factors degrades by exactly the fraction of time the screen is dark, and the realistic ranges for those factors are the ones we laid out in the occupancy math piece.

Why screens go dark, in order of frequency

DHCP lease expiry and captive portals. Guest networks commonly isolate clients, rotate leases on short cycles, or force captive portal re-authentication periodically. A TV that authenticates once at install and then fails to re-authenticate at 3am on Tuesday is the single most common dark-screen cause we see. The screen does not crash; it simply loses its gateway and sits there.

DNS failure. The second most common. Ad content delivery is heavily DNS-dependent, and the DNS servers handed out by guest networks are often the least maintained part of the infrastructure. When DNS dies, everything looks alive and nothing loads.

TV platform quirks. Smart TV operating systems are not managed endpoints. They background-kill apps to free memory, install updates at inopportune times, and occasionally require a power cycle that nothing short of a physical reboot delivers. Which platforms tolerate always-on app duty and which fight you is covered in our platform comparison.

Physical interruption. Guests unplug TVs. Sometimes to charge a phone, sometimes because the standby light bothered them, occasionally out of curiosity about the HDMI stick. Housekeeping replugs some of them. Not all.

The uptime toolkit, in order of impact

Cache aggressively, at the screen. The player should hold a rolling buffer of ad creative and upsell content locally, measured in days, not minutes. A screen that can run its full rotation for 72 hours without network contact loses almost nothing to a weekend of flaky Wi-Fi, and re-syncs silently when the network returns. This one design decision converts most network outages from revenue events into invisible events.

Degrade, never spinner. When the network is gone and the cache runs down, the fallback is not a loading screen. It is a static, locally held holding card with the property's own branding and the core upsell information, which costs nothing and keeps the screen useful to guests. A spinner communicates broken; a branded card communicates intent.

Heartbeats, per screen, with alerting. Every screen reports in on a schedule. The critical metric is not raw heartbeat presence but heartbeat gap patterns. A screen that misses one heartbeat is noise. A screen that misses its window three times in a row, or that heartbeats only between 2am and 4am when the network is quiet, is telling you it is effectively offline during the hours that matter. Dashboards that show only current status hide this completely; you need gap history.

A defined reboot path per platform. Know, before deployment, how each screen model recovers from a wedged app: remote reboot via the platform API where it exists, scheduled nightly restarts as a prophylactic, smart plugs on the property's own power circuit as the last resort, and a physical check cadence for the properties too far away for anything else. Write it down per property. The middle of an outage is the wrong time to discover the API reboot is unsupported on that firmware.

Network pre-flight, then periodic re-flight. The four network questions that decide whether a pilot works at all, guest isolation, peak bandwidth, captive portal behaviour and power circuits, are the ones we set out in the network readiness checklist. What operators miss is that the answers decay. The property changes Wi-Fi vendors, resets the controller to defaults after a support call, or turns on a portal feature nobody told you about. Re-run the checklist quarterly.

Reboot politics and housekeeping

The dark screens nobody catches are the ones that are dark at exactly the moment no staff member is looking. Two low-cost practices close most of that gap. First, make "is the screen showing something sensible" an explicit housekeeping check item, with a yes/no per room, not an impression. Second, agree with the property who physically replugs an unplugged screen and how that gets reported. This sounds like trivial operational detail. It is also frequently the difference between an 85 percent and a 97 percent effective uptime figure, which is the difference between a program that pays and one that quietly dies.

What to put in the contract

Uptime responsibilities should be explicit: who monitors, who performs remote reboots, who performs physical interventions, target effective uptime, and how gaps are measured and reported. Ad buyers are increasingly sophisticated about verifying delivered impressions rather than trusting scheduled ones, and a program that cannot produce honest uptime and delivery numbers will not keep premium buyers the second season.

Screen uptime is not glamorous work. It is caching, heartbeats, checklists and a housekeeping line item. But of all the levers an operator can pull, it is the one that defends every other number in the model at once.

Running screens across multiple properties? AdVision Connect's player caches content locally and heartbeats per screen, so a flaky guest network pauses sync instead of pausing revenue. Talk to us about a pilot.