Server Controls and Logs

The Live section of a game page#

Once a game is live, its sidebar gains a Live group with four entries. Three of them are covered here; the fourth is documented with moderation.

Visibility follows the capability matrix in Members, roles and staff: Overview and Logs need server.read, Server needs server.shutdown. Opening a gated URL directly shows an "Insufficient permissions" message naming the missing capability.

All of these pages talk to the production server only. Test and beta servers report nothing here; use the editor's log viewer (or the read_server_logs MCP tool) for those.

How the server and the dashboard talk#

The game server polls the platform every 5 seconds for its control state and posts health telemetry on the same cadence. Everything on these pages flows through that loop:

• A control change you make (drain, banner, shutdown) is picked up by the server on its next poll, so expect up to about five seconds before players see it.
• The Overview page refreshes its numbers every 5 seconds while the tab is visible.
• Log lines are shipped to the platform in one-second batches.

Every button on the Server page writes an entry to the game's Audit log with the action name (for example server.drain, server.announce, server.shutdown_scheduled), so your team can always see who did what and when.

Overview: server health#

The header shows a status pill computed from the latest snapshot:

Below it, five tiles report the current values:

A freshly started server posts its first snapshot within about ten seconds; until then the page says "No telemetry has been received yet."

History charts#

The History card draws four area charts — Concurrent users, Tick rate (Hz), CPU (%) and Memory (MB) — over a selectable window:

Hover a chart for the exact value at a point in time. A range with no samples shows "No data yet for this range." Health samples are retained for roughly a month; the 7-day view is the longest the page offers.

Server: operator controls#

The Server controls page opens with a status card and four control cards.

Status card#

Broadcast to players#

Pushes a banner above every online player's chatbox. Players receive it within about five seconds.

1. Type the message (up to 200 characters in the form).
2. Optionally tick Auto-hide after and enter a number of minutes (default 5). Leave it unticked for a banner that stays until you clear it.
3. Click Send banner. The message appears in the status card as Live banner.
4. Click Clear banner to remove it from every client.

A persistent banner is re-sent to players who log in after it was posted; a timed banner is not, because its countdown would already be stale for them. Timed banners are capped at 24 hours.

Drain mode#

Drain new connections stops the server accepting new logins while everyone already in the game keeps playing. New connection attempts are rejected with your maintenance message (or a default one). The state pill switches to Draining and the button becomes Resume accepting players.

Use drain before a planned shutdown so the population winds down on its own, or while you investigate a problem without kicking anyone.

Maintenance message#

The maintenance text is shown on the game's launcher card and is the rejection message players see while the server is draining or shutting down.

1. Enter the message (the API accepts up to 500 characters).
2. Optionally set Until (optional). The message clears itself once that time passes; a window longer than 72 hours is shortened to 72 hours.
3. Click Set message (or Update message if one is already active). Clear removes it immediately.

Restart and shutdown#

Restart stops the server and brings it back online right after. Shutdown stops it and leaves it offline until you bring it back. Both share a When selector:

For a scheduled time, the card previews the warning timeline — T-10min warning, T-5min warning, T-1min warning and Restart fires — and the status card shows the countdown. Scheduled restarts and shutdowns are independent: you can cancel either with Cancel scheduled restart or Cancel scheduled shutdown.

What players experience:

• Immediate restart or shutdown — the server exits at its next poll, within about five seconds. Player saves flush during the normal shutdown sequence; there is no countdown banner. The platform also force-stops the container 45 seconds later as a safety net in case the in-game module did not react. After a restart the platform brings the container back up.
• Scheduled shutdown — the server broadcasts warnings at the 10-, 5- and 1-minute marks, stops accepting new connections at the end, shows a 30-second shutdown countdown with your maintenance message as the reason, saves every connected player and exits.
• Scheduled restart — the server broadcasts the same 10-, 5- and 1-minute warnings so players can wrap up.

To shut down:

1. Choose When.
2. Click Shutdown (or Schedule shutdown). A dialog titled Shut down server? explains what will happen.
3. Type the game name exactly as shown and click Shut down now (or Schedule shutdown).

An immediate restart asks for a simple confirmation instead of the typed name.

While the server is Stopped, the card collapses to a single Bring back online button. Bringing it back also clears any scheduled restart.

Recommended sequence for planned maintenance#

1. Set a Maintenance message with an Until time so the launcher explains the downtime.
2. Send banner to tell players in-game what is coming.
3. Choose In minutes (for example 15) and Schedule shutdown or Schedule restart.
4. Optionally Drain new connections so nobody joins in the last minutes.
5. After the work, Bring back online (if you shut down), Resume accepting players, and Clear the maintenance message.

Server activity timeline#

The History tab of the game page (not the Live section) has a Server Activity timeline above the version history. It records lifecycle events rather than operator clicks: Launched, Brought online, Taken offline, Unexpected outage, Recovered, Update deployed, Hotfix, Rolled back, Hosting canceled, Hosting resumed and Offline (billing), each with a timestamp and an optional message. Events the platform generated on its own carry an auto tag. Use Load older events to page back. For what triggers deploy-related events, see Updates, patches and rollback.

Player activity feed#

The Players page in the Live group ends with an Activity table: a structured stream of recorded player actions, distinct from the raw server logs. The same feed is available on its own at /dashboard/{gameId}/activity (it needs players.read). Filter it by Type, by exact Player id, and by From / To; 200 events load at a time, with Load older entries at the bottom. Each row links the player name to their profile.

Activity is retained for about 30 days, which is also the window the players source in the Data browser and the retention charts in Analytics draw from. Moderation actions on what you find here are covered in Players and moderation.

Logs#

The Server logs page combines a live tail with a searchable history of everything the server's logger emitted.

Reading the table#

Each row shows the time (to the millisecond), the level (debug, info, warn, error), a tag naming the subsystem that wrote the line, and the message. Long messages are truncated unless you tick Wrap long lines. Right-click any row for:

• Pin pattern — adds the first 60 characters of the message to a Pinned list; matching text is highlighted in every row. Pins are saved in your browser. Click a pinned chip to remove it.
• Copy message — copies the full message to the clipboard.

Filters#

Filters apply to both the stored history and the live stream. History loads 200 entries at a time; scroll to the bottom (or click Load more) to fetch older ones. The counter above the table shows how many entries match and whether older ones are available.

Live tail#

Live: ON opens a streaming connection and prepends new lines as they arrive; the badge next to it reads Connecting…, Live, Disconnected or Idle (when live is off). The browser keeps at most 5,000 buffered lines. If the connection drops, the page retries with increasing delays up to five times and then shows "Live tail disconnected — click to retry". A role without log access is refused and live is switched off.

Export#

1. Set From and To.
2. Click Export NDJSON.

Your browser downloads logs-{gameId}-{from}-to-{to}.ndjson, one JSON object per line, covering the whole window regardless of the level, tag and search filters. A busy server can produce a very large file for a 24-hour window.

What is kept, and what is not#

• The server ships info and above by default, so the debug toggle is usually empty.
• History is retained for about two weeks. Export anything you need to keep.
• Lines written by platform modules carry tags such as ControlPlane, DataSnapshot, PlayerAutosave, ActivityLogger and TelemetryModule. The DataSnapshot tag is where backup problems are reported — see Data browser.
• Only entries that go through the server's structured logger reach this page. Plain console output (including the Log() helper on a module) goes to the container console, which you can read from the editor instead.

With AI (MCP)#

read_server_logs tails the container console of a deployed server (test by default; pass mode: "live" or "beta") and returns up to 2,000 recent lines with contains, exclude and min_level filters. It reads the raw console stream, so it also shows unlevelled output that the dashboard's structured feed does not carry. get_live_status and get_deploy_status report the deployment state that the dashboard's header badges summarize.