Skip to content

Monitoring and troubleshooting ​

The live logs, and the tools for when a guest cannot get on: a diagnostic run of an account, a simulated portal visit, the session debugger, and a live controller test against the real hardware.

Nearly every page below is permission-gated. If a colleague cannot see one, that is their role rather than a fault — Roles is where to look.

Monitoring ​

Alerts ​

/admin/monitoring/alerts

Everything on the site that needs attention, from every check Kiwire runs every 30 minutes — failing guest messages, guests turned away, quiet controllers, configuration gaps, integrations, licence and certificates, scheduled tasks, voucher stock and campaigns.

When you would open it. Seeing why guests are having trouble before they call, and acknowledging, snoozing or ignoring what you have dealt with.

Before it has anything on it. Nothing — the checks run for every site whether or not KAIA is on, and use no AI. An empty page means nothing is wrong.

Needs the view-alerts permission.

→ Alerts

Captive Portal Log ​

/admin/monitoring/log/portal

The raw captive-portal request/event log — browsable by hour, with search and a plain-text export, read live from the log files rather than a database table.

When you would open it. Tracing exactly what the portal logged for one guest's login attempt, or watching a live tail while reproducing a reported issue.

Before it has anything on it. Log files only exist for hours the portal actually received traffic — an hour with nothing logged is a normal empty result, not an error. Exports are capped at 31 days per run.

Needs the view-portal-log permission.

PMS Log ​

/admin/monitoring/log/pms

The raw log of PMS (hotel property-management system) integration traffic — the same browsable, searchable, exportable log viewer as Captive Portal Log, pointed at the PMS integration's own log files instead.

When you would open it. Tracing a stuck or failed PMS check-in/check-out sync, or watching a live tail while reproducing an integration issue with the front-desk system.

Before it has anything on it. A PMS connector actually configured and sending data — without one, these log files stay empty.

Needs the view-pms-log permission.

Troubleshoot ​

Diagnostic Account ​

/admin/accounts/diagnostic-account

A login simulator for one existing account — runs the same checks a real captive-portal login would (password, capacity, licence quota, status, policy, expiry, zone/MAC, quota, simultaneous-login and more, in the order the real pipeline evaluates them) and shows a pass/fail checklist naming the exact stage that would reject it.

When you would open it. A specific guest says they can't log in and you need to know exactly why — expired account, wrong zone, exhausted quota, a policy block — instead of piecing it together from the account edit screen.

Before it has anything on it. An existing username on this tenant. The duplicate-login guard and the licence monthly quota are always shown as "skipped" — a diagnostic run deliberately never counts against them; if no password is typed, the account's stored password is used and the checklist notes that instead of testing what you typed.

Needs the view-diagnostic-account permission.

Portal Simulation ​

/admin/captive-portal/simulation

A tool that opens the real, live captive-portal login page — in an in-page phone frame or a new browser tab/window — pre-filled with synthetic controller-redirect parameters (a random MAC and IP, plus the VLAN/SSID/IP your selected zone's matching rule would send) standing in for a genuine NAS redirect.

When you would open it. Testing a journey, template or login method end to end — including a real credential check and the real success page — without walking out to the network, or demonstrating the portal to a client from a desk.

Before it has anything on it. At least one active controller, whose vendor login-config supplies the redirect parameter names the form fills in; a zone with a detection rule to get realistic VLAN/SSID/IP prefills instead of random values.

What's simulated and what's real: the login page, credential check and success/redirect all run for real against the actual portal — the request is simply marked with a simulation flag that shows up in logging and messages. What's synthetic is only the controller side of the handshake: a made-up MAC/IP and a zone rule's VLAN/SSID stand in for a genuine device and NAS. A previous simulated login leaves auto-login cookies, a fingerprint token and MAC device history behind, which make the next launch skip straight past the login page — use Reset first to clear those traces.

Needs the view-portal-simulation permission.

Portal Session Debugger ​

/admin/monitoring/portal-session

A lookup tool for one guest's captive-portal session — by session ID or MAC address — showing the full session payload (secrets masked), the matching portal log lines, and a preview of the journey pages it passed through.

When you would open it. A guest is stuck partway through login and you have their session ID or MAC in hand — see exactly what the session recorded: which controller/zone it resolved to, what stage it reached, and what the log said at that moment.

Before it has anything on it. A session ID (20-128 alphanumeric characters, as the portal URL carries it) or a MAC in aa:bb:cc:dd:ee:ff form. A tenant admin only ever sees sessions belonging to their own tenant, whatever ID they search for.

Needs the view-portal-session permission.

Controller Test ​

/admin/monitoring/controller-test

A live capture tool — open a short-lived listening window and it shows, hit by hit as they arrive, the exact parameters a WiFi controller/NAS sends to the captive-portal entry point, each checked against a vendor-specific pass/fail checklist.

When you would open it. A new controller's redirect isn't landing guests correctly and you need to see, in real time, what it's actually sending — a wrong parameter name, a missing MAC, the wrong NAS ID — while someone connects a test device to it.

Before it has anything on it. A device (or the Portal Simulation tool) actually hitting the portal URL while the capture window is open — this is a live capture, not a log replay, so nothing shows if nothing arrives. The window stays open only while the page keeps polling it, and expires after 90 seconds idle.

Needs the view-controller-log permission.


This list is read from the admin menu itself, so it cannot fall behind it.

Last updated:

Kiwire platform documentation