# LiveKit live operations console for room moderation

> Watch every live room on one screen, remove disruptive guests, start recordings and end stuck sessions without anyone opening a terminal.

- Workflow type: app
- Services: LiveKit, Slack Bot, General Input Database
- Categories: Operations, Customer Support
- Published: 2026-08-31

## What it does

- Shows every live room on one auto refreshing screen with how many people are in it, how long it has been running, whether it is being recorded and whether an AI agent worker has joined.
- Lets moderators act on the spot: remove a disruptive guest, change what someone is allowed to share, post a notice to the whole room, start or stop a recording, bring in an agent, or end a session that is stuck.
- Pushes the rooms that need attention to the top, so empty rooms and failed recordings are the first thing anyone sees.
- Adds a Diagnose button that has an assistant read the room and write a plain language explanation of what looks wrong, then post it to Slack when the room is broken.
- Keeps a permanent record of every moderator action, including who did it and when, which LiveKit itself does not store.

## What you'll need

- A LiveKit account with API access to the project your rooms run in
- A Slack workspace where the app can post problem reports to a channel
- A General Input database to hold the action log and diagnosis notes, which gets created for you
- The names of any agent workers you want moderators to be able to attach to a room

## Prompt

Build me a live operations console for LiveKit that my support and event ops team keeps open on a second monitor while sessions are running, so they can see and fix problems without anyone opening a terminal. The audience is support staff, event ops and live class moderators, not engineers.

The main view is an auto refreshing grid of every active room, loaded with LiveKit List Rooms. Each row shows the room name, the participant count, how long the room has been up based on its creation time, whether a recording is currently running based on List Egress for that room, and whether an agent worker is attached based on List Agent Dispatches. Refresh the whole grid on a short interval of about ten seconds. LiveKit list endpoints return the full result set with no pagination, so one refresh is a single call per resource and the grid can safely reload everything each time.

Sort so the rooms that need attention come first: rooms with zero participants and rooms whose most recent egress record is in a failed state go to the top, then the rest ordered by longest running. Give each row a clear status chip for recording state and for agent state so a moderator can scan the grid at a glance from a few feet away.

Expanding a row lists everyone in the room using List Participants, showing identity, display name, join time, what they are currently publishing such as audio, video or screen share, and their connection quality. When the operator opens a single participant detail panel, load that person with Get Participant.

From each room row, and from each participant inside an expanded row, the operator can act immediately. Remove Participant disconnects a disruptive participant. Update Participant changes what someone is allowed to publish. Update Subscriptions changes which tracks a participant is subscribed to. Update Room Metadata posts a notice to everyone in the room. Start Room Composite Egress begins a recording and Stop Egress ends one. Create Agent Dispatch attaches an agent worker to the room. Delete Room ends a stuck session and disconnects everyone.

Every one of these actions is either destructive or immediately visible to people in a live session, so each one opens a confirmation dialog naming the room and the affected participant before it fires. Nothing acts on a single click.

LiveKit keeps no audit trail of its own, so log every moderator action to the General Input Database: the action taken, the room name, the participant identity where one applies, the arguments used, the result returned, the signed in app viewer who did it, and the timestamp. Add a second view in the app that shows this log newest first and lets the team filter it by room, so they can answer questions like who ended that session after the fact.

Each room row also has a Diagnose this room button that kicks off a background agent. The agent reads the room with List Rooms, its participants with List Participants, its recordings with List Egress and its agent dispatches with List Agent Dispatches, then writes a plain language health note back into the app saying things like nobody is publishing audio, the recording failed to start, or no agent ever joined. Store each note in the database with its room and timestamp so the app can show the latest diagnosis on the room row and keep the history. When the diagnosis reads as broken rather than healthy, the agent also posts the note to a Slack channel using Slack Bot Send a Message, naming the room and what looks wrong.

Favour density and readability over decoration throughout. This screen is watched in real time while sessions are live, so problem rows need to be visually obvious and the moderator controls need to be reachable in one or two clicks from the grid.

## How to customize

- How often the grid refreshes and which columns show on each room row
- Which Slack channel receives diagnosis reports, and whether healthy rooms get reported too
- What counts as a problem room for sorting, such as flagging any room that has sat empty for more than a few minutes
- Which actions live on the room row versus inside the participant detail panel

## FAQ

### Do moderators need to be technical to use this?

No. Everything is a button on a screen. Today these actions are only available as signed API calls, which is why teams end up asking an engineer to remove someone or stop a recording mid session. This puts the same controls in front of the people actually watching the sessions.

### Will it show rooms created by my own app or voice agents?

Yes. The console lists whatever is live in your LiveKit project right now, no matter what created the room, so rooms opened by your product, your agents or a scheduled class all appear in the same grid.

### Does LiveKit already keep a record of who removed a participant?

No, and that is one of the reasons for this app. Every action taken here is written to your own database with the room, the person affected, who clicked the button and the time, so you can answer questions about a session long after it ends.

### Can I start a recording for a room that was not set up to record in advance?

Yes. A moderator can start a full room recording on any live room from its row, and stop it from the same place. The row shows whether a recording is currently running so nobody starts a second one by mistake.

### What does the Diagnose button actually do?

It runs an assistant in the background that reads the room, everyone in it, its recordings and its agent workers, then writes a short plain language note such as nobody is publishing audio, the recording failed to start, or no agent ever joined. The note appears on the room row, and when the room looks broken it also goes to your Slack channel.

### Can someone end a live session by accident?

Every action asks for confirmation first and names the room and the person it affects, so nothing fires on a single click. Ending a session and removing a participant both go through the same confirmation step.

Use this prompt in General Input: https://www.generalinput.com/prompts/livekit-live-operations-console-for-room-moderation