Monitoring Guest WiFi Uptime: What to Watch, What to Alert On, Who Fixes What

Downtime Is Silent Until It Is Not

A guest WiFi outage has a peculiar property: nobody official notices. The kitchen still fires, cards still process on the separate POS network, and the first report arrives as a guest complaint mid-rush, hours after the actual failure. Meanwhile every one of those hours was a hole in the capture funnel: connections not made, contacts not collected, review requests not sent.

Venues do not need an enterprise network operations center. They need to understand the chain of things that can fail, a small set of checks that notice failures before guests do, and absolute clarity about who fixes which layer. This guide covers all three, written for operators running the two hardware ecosystems we support, TP-Link Omada and Ubiquiti UniFi.

The Failure Chain, Layer by Layer

Guest WiFi is a chain of six links, and the guest-facing symptom tells you surprisingly little about which link broke. Learn the chain and diagnosis gets fast.

1. The internet line. The ISP connection into the building. When it fails, everything downstream looks alive: the network name broadcasts, the portal may even load from cache behavior oddly, but nothing reaches the internet. Symptom: connected, no internet, all devices, all SSIDs including staff.

2. The router or gateway. Local routing, DHCP, VLANs. When it fails or its DHCP pool exhausts, devices join the network but get no address or no route. Symptom: stuck on "obtaining IP address," or connected with no traffic flowing, while the modem's own status lights look fine.

3. The controller. The Omada controller, hardware or software, or the UniFi console. This one is subtle: access points can keep serving existing sessions while the controller is down, but new portal authentications fail, because the auth handshake needs the controller. Symptom: guests who were online stay online, new guests see the portal but never get through it.

4. The access points. A single AP failing creates a coverage hole rather than an outage: WiFi works at the bar, dies on the terrace. Symptom: location-specific complaints. Power issues, especially PoE budget problems after someone adds a camera to the same switch, are a classic cause.

5. The captive portal. The hosted portal page and the authentication callback. If the portal service is unreachable or misconfigured, guests associate with the network but the sign-in page errors or never appears. Symptom: network joins fine, portal blank or erroring, on multiple devices.

6. DNS and the walled garden. Captive portal detection depends on redirects and a correctly whitelisted set of pre-auth domains. Configuration drift here, often after some other change, produces the maddening "it works on Android but not iPhone" class of bug. Symptom: device-specific portal weirdness.

What to Monitor, Practically

Use the monitoring you already own. Both ecosystems ship real alerting that most venues never switch on. In Omada, enable controller notifications for AP disconnection and ISP load; in UniFi, enable console alerts for device offline events. These are free, and they cover layers 3 and 4 with zero extra tooling.

Add one external uptime check. An outside service pinging your connection, or your controller's remote status, catches layer 1 and 2 failures overnight and on closed days, when nobody is in the building to notice. Even a basic free-tier checker that emails you is a large upgrade over guest-powered detection.

Walk the funnel once a day. The single highest-value ritual costs sixty seconds at open: a staff phone forgets the network, rejoins, sees the portal, completes it with a test address, reaches the internet. That one pass exercises all six layers end to end. Put it on the opening checklist next to turning on the lights.

Watch the capture graph. Your portal dashboard is itself a monitor: a day with normal footfall and near-zero new connections is a red flag that something upstream broke quietly. Sudden silence in the data is a symptom, not a coincidence.

What Deserves an Alert

Alert fatigue kills monitoring, so keep the list short and severe:

• Internet line down for more than five minutes: page the owner or manager.
• Controller unreachable for more than five minutes: page whoever administers the network.
• Any AP offline for more than ten minutes during opening hours: notify, not page.
• Portal completions at zero for two consecutive opening hours: notify and run the sixty-second walk.

Everything else, channel congestion, a single device misbehaving, one failed authentication, belongs in a weekly review, not a 2am message.

Who Fixes What

Outages stretch into days when nobody is sure whose problem it is. Write this table down, fill in the names, and laminate it:

The escalation card for staff needs only three lines: try the modem-and-router reboot sequence below if a manager approves, then call the IT contact, then report to the portal support channel. Staff should never be improvising network surgery mid-shift.

The Reboot Order, and What Never to Touch

When a manager does reboot, sequence matters: modem first, wait for its lights to settle, then router, then controller, then access points if needed. Rebooting in random order produces devices that come up before the thing they depend on. Two standing rules: never factory-reset anything while troubleshooting, a reset converts a ten-minute outage into a rebuild project, and never change portal or SSID settings as a "fix" during an incident. Restore service, then investigate.

For extended outages where the auth service is unreachable but the internet is fine, having a documented break-glass option, a hidden open SSID that a manager can enable and later disable, keeps guests served while the real fix happens. Decide in advance whether that trade-off suits your venue; deciding at 7pm on a Friday is how temporary networks become permanent capture leaks.

Measure It Like It Matters

Track two numbers monthly: uptime percentage during opening hours, with anything under 99.5 percent worth a root-cause conversation, and mean time to detection, the gap between when a failure started and when someone knew. The first number is about your infrastructure. The second is about your process, and it is the one the daily sixty-second walk and the external check will transform.

Setup guides for both ecosystems cover the alerting features in context: see the Omada setup guide and the UniFi overview, or the platform pages for TP-Link Omada and Ubiquiti UniFi. The capture funnel only compounds while the lights are on. Make sure someone, or something, is watching the lights.