Network resilience

Venue Wi-Fi is the leading cause of "this sign is acting up" support tickets. The hardware works, the kiosk works, the dashboard works — and the wall keeps showing the right content because Chromium's standard HTTP cache holds whatever the kiosk has already loaded — but the dashboard reports problems because the venue network drops the connection back to backend.

This page is an operational playbook for surviving venue networks. The core principle: plan for the venue network to fail, design every layer to keep the wall correct anyway.

Wired Ethernet, every time

When given the choice, run a cable.

Why:

• Stability. A wired connection has no roaming, no signal-strength variance, no AP saturation, no captive-portal re-prompts.
• Throughput. A 1 Gbps wired link beats venue Wi-Fi even at peak.
• Predictability. A wired link doesn't change behavior when 500 attendees show up with phones.
• No SSID surprises. No "they changed the password an hour ago and didn't tell us."

When you can't:

• Rented venues that don't allow you to run cable
• Mobile / floor-pop signage that has to move during the event
• Last-minute adds where venue IT won't run a port

Mitigation: a portable AP on your own LTE/5G feed. A travel-class router with a cellular modem produces a controlled SSID you can put your kiosks on. Costs vary widely by brand and data plan — get a current quote — but for tier-1 events, running your own backup network is usually cheap relative to the cost of a venue-network failure during a keynote.

Wi-Fi when you must

If the kiosk is on Wi-Fi, the rules change. Wi-Fi signage has a much higher failure rate than wired and demands more pre-event preparation.

Pre-stage SSIDs in the image

Pre-load every venue SSID into the kiosk image so the kiosk auto-joins on first boot without anyone typing a password:

• See Base Windows setup → Pre-stage venue WiFi profiles.
• Stack as many SSIDs as you need for the show — Windows auto-joins the first in range.
• Pre-staging is non-negotiable for unattended deployment. A kiosk asking for a Wi-Fi password is a kiosk that can't claim itself.

Prefer hidden SSIDs over open networks with captive portals

If the venue offers a choice between:

• Open Wi-Fi with a captive portal (typical guest network)
• Hidden SSID with a WPA2 passphrase (typical staff network)

Choose the hidden SSID. Captive portals routinely:

• Re-prompt for terms acceptance at unpredictable intervals
• Block long-lived WebSocket connections
• Inject HTTP redirects that look like content failures
• Limit bandwidth aggressively during peak hours

A hidden SSID with a passphrase that's stable and pre-staged is the closest Wi-Fi gets to wired behavior.

Avoid guest Wi-Fi specifically

Guest Wi-Fi networks routinely have:

• Client isolation — clients can't reach each other. Kiosks don't need to, but it's a flag.
• Bandwidth caps per client. Fine for sign-day traffic; can break content first-loads with large assets.
• Aggressive QoS that prioritizes other traffic during peak times.
• Periodic re-authentication every N hours.

If the venue's only option is "guest Wi-Fi," that's a flag worth raising with the event organizer before load-in.

AP placement matters

Wi-Fi signal strength varies by 10-20 dB across a single conference room. Place kiosks within ~30 ft of a known good AP, with line of sight if possible. Don't trust "the venue says coverage is everywhere" — verify with a survey app on your phone at the actual sign location during load-in.

DNS

Standard DNS works. A few nuances:

• Captive portals intercept DNS. The kiosk's DNS server is the venue's, and that server may rewrite responses for unauthenticated clients. Pre-stage SSIDs avoid this.
• Public DNS as a fallback. If venue DNS is misbehaving, set the kiosk's interface to use 1.1.1.1 + 8.8.8.8. This bypasses the venue resolver but still requires the venue to allow outbound DNS to those IPs (port 53 UDP).
• NTP via DNS. Time-sync depends on resolving time.windows.com or your chosen NTP server. If clocks drift far enough, TLS handshakes start failing and the kiosk can't reach backend. NTP traffic over UDP 123 outbound — see Network requirements → DHCP, DNS, NTP.

The offline cache as your safety net

The desktop sign relies on Chromium's standard HTTP cache for webpages. When the network drops, a page already loaded into the kiosk keeps rendering as long as its assets are cache-friendly.

Practically:

• Brief outages (under a few minutes): invisible if the cache covered the page's assets. The wall looks the same. The dashboard transitions the sign to Offline; the wall keeps working.
• Extended outages (hours): the cached version continues to display if it doesn't depend on live network calls. See Content design → Designing for offline survival.

This is your safety net for venue Wi-Fi flapping. Build content that doesn't depend on live API fetches and a 30-second connection drop is invisible to attendees.

Reachability-check timing

The kiosk checks its assigned content URL on a regular cadence — roughly every minute — and needs 2 consecutive failures before it transitions to "content unreachable" state (about a 2-minute window total).

This is why brief venue-Wi-Fi blips don't immediately mark content unreachable: a single 30-second hiccup recovers before the second check. The cadence is tuned for event-floor reality where the network momentarily drops more often than it actually fails.

See Notifications → Brief outages stay silent for what happens on the notification side once unreachable is sustained past 60 seconds.

Failover patterns

For tier-1 events where downtime is unacceptable, layer redundancy:

Two networks per kiosk

• Wired Ethernet primary, with a Wi-Fi profile pre-staged.
• Windows auto-fails over to Wi-Fi if Ethernet drops; the WebSocket reconnects.
• Costs nothing if you've already pre-staged the SSID.

Portable AP backup

• Run a portable AP on your own LTE feed throughout the event.
• Pre-stage its SSID into the image as the last-resort profile.
• If venue Wi-Fi falls over completely, your AP keeps signs reaching backend.

Fallback content URL

• Your primary content URL is on a third-party origin or a complex CMS.
• Build a simpler fallback URL (static HTML on Cloudflare Pages, GitHub Pages, etc.) that can serve as a "last good known" page.
• Switch signs to the fallback URL when the primary breaks.

Detecting flapping

A few patterns the dashboard will surface:

• Constant offline-online toggles in the sign's audit log → Wi-Fi roaming or AP saturation. See Sign shows offline → flapping.
• All signs flapping at once → backbone-level issue. Coordinate with venue IT.
• Signs in one specific area flapping, others fine → bad AP or RF dead zone in that area. Move kiosks closer to a different AP.

The per-sign EventLog card on the sign detail page (collapsed by default) is the easiest way to spot patterns — expand it across a few signs to see whether transitions cluster in time, which usually points at the network rather than the individual signs.

Coordinate with venue IT

Most venue IT teams are great. A few patterns make working with them smoother:

• Send the outbound allowlist ahead of load-in. In writing, with timestamps, so it's documented if it gets walked back.
• Show up with the Network requirements page printed. Gives venue IT something concrete to refer to.
• Confirm allowlisting from a kiosk during load-in, not just from a venue IT laptop. Differences matter.
• Ask about captive portals upfront. If they exist, you want to know before kiosks are unboxed.
• Get an IT contact for the event window. Not the helpdesk; a phone-callable person.

What not to do

• Don't try to "fix" Wi-Fi by tuning the kiosk's TCP stack or WebSocket parameters. The venue network is the constraint. Fix it at the venue, or fail over to a network you control.
• Don't disable the offline cache to "force fresh content." The cache is a safety net, not an inconvenience. The reachability monitor handles update detection.
• Don't share an SSID password with attendees. The "staff" SSID is staff-only for a reason.

See also

• Network requirements — the outbound allowlist and bandwidth specs
• Content design → Designing for offline survival — page-side patterns that survive
• Sign shows offline — diagnosing offline transitions
• Stability over features — why the conservative defaults pair with network resilience