Watching live activity with the Monitor

What the Monitor is, and is not

The Monitor is an internal, administrator-only page that shows who is using the app right now. For each visitor it shows their current page, how recently they were active, and a short log of the pages they just moved through. It is an operational tool, useful for questions like whether anyone is mid-task before you take the app down. Most users never need it and never see it.

The page states its own scope: "Sessions show current path and recent navigation activity (heartbeats). No screen capture." It does not record what is on anyone's screen. In normal use it records no clicks and no typing, only which pages were visited and when.

Two locks on the door

Access has two layers. First, the Monitor is limited to administrators, set in the app's code. It is not a capability you can grant in Role Management, so anyone who is signed in but not an administrator sees "Admin access required." and nothing else.

Second, even administrators must enter a separate Monitor password. This is not your login. It is a dedicated password configured on the server by whoever operates your deployment, and it cannot be set or changed from inside the app. Once accepted, a secure browser cookie keeps the Monitor unlocked for 24 hours. After that, or if you clear cookies or switch browsers, you are asked again.

1. 1Open the Monitor page. While your role is checked you will briefly see "Loading…".
2. 2On the Monitor Access screen, type the Monitor password into the Password field and click Enter.
3. 3If "Invalid password" appears in red, it does not match the server's value, so ask your deployment operator for the current one and try again.
4. 4If you see "Monitor access is not configured (MONITOR_PASSWORD unset)", no password has been set yet and the operator must configure one before the page can open.

Reading the session grid

After unlocking, you get a responsive grid of cards, one per active visitor, with the most recently active first. Each card shows a status dot, green if the visitor was active within the last 60 seconds (tooltip "Live") and red once they have gone quiet (tooltip "Closed"). It also shows the visitor's signed-in email, or "Anonymous" for someone not logged in such as a person filling out a public form. Anonymous visitors are tracked the same way as signed-in ones.

Each card also shows the current path in a bordered box, the time they were last seen, and a Logs section you can open and close. If nobody is browsing, the page reads "No active sessions. Activity will appear as users browse the app."

Two design choices keep the grid readable. Visitors coming from the same network address are merged into one card, with their logs combined, so one person with several tabs open is still one card. And your own Monitor session is left out, since browsing the Monitor generates no tracking events, so you never watch yourself. A visitor silent for 15 minutes drops off the server entirely.

Logs and the detail view

Opening Logs shows the 15 most recent events, newest first, each with a timestamp. An arrow line means the visitor moved to a new page, and in normal use that is the only thing recorded. A dot marks a click and a keyboard symbol marks an input, but recording clicks and typing is off by default. Only your deployment operator can switch it on, at the server, for one session, and there is no button on the page to do it. The once-a-minute heartbeat each tab sends never appears as a log line.

Event volume is capped. The server keeps up to 50 events per session, the page accumulates up to 120 per card while you keep it open, and the expanded log displays the latest 15.

Clicking a card's current path box opens a floating detail panel showing the visitor's email (or "Anonymous"), their full current path, and last seen as a full date and time. While the panel is open, the page refreshes more often so you can follow that session closely.

1. 1Click a card's ▶ Logs toggle to expand its event log; the arrow rotates when open.
2. 2Read the newest entries at the top, each line carrying its time.
3. 3Click the current path box, or focus it and press Enter or Space, to open the detail panel.
4. 4Click Close, or anywhere outside the panel, to dismiss it.

How fresh the data is

The Monitor checks for updates on a timer rather than receiving them instantly. It re-fetches the session list every 8 seconds normally, and every 4 seconds while a detail panel is open. On the visitor side, each page change is reported right away, and a heartbeat goes out once a minute and whenever a tab regains focus.

So what you see is at most a few seconds behind reality for navigation, while the green-to-red change can lag up to about a minute behind a visitor going quiet. If a card briefly drops out of one refresh, which can happen on serverless hosting, the page keeps it on screen for about 30 seconds so the grid does not flicker.

A deliberately short memory

The Monitor is short-lived by design. Activity lives in the server's memory only, nothing is written to the database, so there is no past activity to look up later. A visitor and all their events are deleted 15 minutes after their last activity, and a server restart or redeploy clears everything at once. Even an active visitor keeps only their 50 most recent events.

There are also no filters, no search, and no export. The grid always shows all active sessions sorted by recency, and with few users at a time, scanning it is the intended workflow. If you need a lasting record of something you saw, take a screenshot or note it down before it ages out.

That plainness is the point, and it stays light on performance. Each visitor sends one small request per page change plus one heartbeat a minute, the server holds everything in memory with small caps, and the Monitor only adds polling for whoever has it open. Nobody's app runs slower because the Monitor exists.

Troubleshooting

Most snags come back to the two locks or the short memory.

1. 1"Admin access required." means you are not signed in as an administrator; this page cannot be granted through capabilities.
2. 2"Invalid password" means the Monitor password does not match the server's value, which is separate from your login; ask your deployment operator.
3. 3"Monitor access is not configured (MONITOR_PASSWORD unset)" means no password is set yet, so the page cannot open until the operator configures one.
4. 4Being asked for the password again is normal; the unlock cookie lasts 24 hours per browser, so just re-enter it.
5. 5A user you expected to see may have been idle over 15 minutes, or the server restarted; they reappear as soon as they navigate anywhere.
6. 6A card that seems to mix two people is two sessions sharing one network address, merged into one card, showing the email of the most recently active session.