Change Log

The Change Log (sidebar, Security) lists every change that somebody made through this web interface: who, where, with which values, and how it ended. It is for admins only and records on its own - nothing has to be switched on. Commands typed into the Query Console are not repeated here; the console keeps its own audit trail.

What is recorded

One row for every request that changes something - creating, editing, deleting, moving, starting, stopping, sending. Opening a page or reading a list never writes a row. Each row carries:

the time and the user, with the role they had at that moment,
the change: the method (POST, PUT, PATCH, DELETE), the area (for example channels, server-groups, bans, users, servers, settings, playlists, bots) and the route with its ids named, such as /servers/:configId/vs/:sid/channels/:id,
the target: the server connection by name, the virtual server and the id of the object (a channel, a group, a user, ...),
the values sent, behind a click in the row, and for the most important targets what the change did: before and after (see below),
the result: succeeded, failed or denied, with the HTTP status and, for a failure, the reason - TeamSpeak's own, with its error code, when the server refused (TeamSpeak API Error: invalid channelID (768)),
how long it took, and the address it came from (see below).

Secrets are never stored. Passwords, API keys, SSH passwords, tokens, the SSO client secret, channel and server passwords and two-factor codes appear only as (changed), never with their value. Where the secret is part of the address itself - deleting a privilege key or a temporary server password - the route shows only its name (…/tokens/:token, …/tokens/temp-passwords/:pw), and the same goes for the optional line in the TeamSpeak server log. A field left empty on purpose - the edit form's "keep the current one" - stays empty, so a saved connection whose password was not touched does not claim it changed. Very long values (an uploaded picture, say) are left out with only their length, and one row keeps at most a few thousand characters of what was sent.

Denied is a change the role check turned away: a Viewer trying something only an admin may do. It is kept on purpose - an attempt to do more than one's role allows is exactly what this page is there to show. The change itself did not happen.

Downloading a backup is recorded too, although it changes nothing: a backup holds password hashes and encrypted credentials. So is a scheduled backup that failed, as a change by system.

A user's own account is recorded too: changing their password, switching two-factor authentication on or off, and the interface language.

Not recorded:

signing in and out, the second sign-in step and the quiet token refresh - the Connection Journal keeps those,
a user's own dashboard layout and similar personal view settings,
a connection's Test button under Settings → Connections and the checks for updates and for the YouTube cookies, which change nothing,
what bot flows and music bots do by themselves; on a connection with a Bot Identity, TeamSpeak's own server log shows a flow's actions under that name.

Before and after

For these changes the row also says what was there before and what it is now, under Before / after in the row's details:

Change	What is kept
Editing a channel	the fields that changed, e.g. `channel_name Lobby → Lounge`
Moving a channel	the parent channel and the position (TeamSpeak keeps the position as "after which channel")
Deleting a channel, a server group or a channel group	the object as it was, every field
Renaming a server or channel group	the old and the new name
Setting or removing a permission of a server group, channel group, channel, channel-client pair or client	only the permissions the change names: value, plus negated and skip when set - not set on the side where it did not exist
Virtual server settings, instance settings	the settings that changed, only those the app actually passes on to TeamSpeak
Deleting a ban	the ban as it was (address, name or unique ID, reason, duration, who set it)
Deleting all bans	how many there were, and the first 100
Deleting a privilege key or a temporary server password	the entry as it was - group, description, times - without the key or password itself

How it works. Right before such a change the app reads the target once from the TeamSpeak server; after is what was sent. That is one extra query per change, which counts against the server's flood limits like every other, and adds one round trip to the change. Only successful changes keep a before/after; a failed or denied one does not, and the read is not even made for a role that may not make the change.

When the read does not work - the server does not answer within 3 seconds, or refuses - the change goes ahead anyway, and its row says that the state before could not be read, and why.

Secrets stay out here as well: a password field reads (changed) on both sides, a deleted privilege key or temporary password is kept without it, and very long values keep only their length. Changes to the app's own data (accounts, roles, server access, connections, app settings) have no before/after.

When a row cannot be written

Changes to users and roles, server connections (with their stored credentials), instance settings and the app's own settings are written before they are made. If the database cannot take the row - a full disk, a locked file - the change is refused with an error saying so, and nothing is changed. A row that stays pending means the backend stopped before the change finished.

Every other change is recorded right after it has been answered. If that row cannot be written, the change still happened; the backend log says that the entry was lost.

When the log is switched off, nothing is refused and nothing is written.

Reading it

The page opens on the last seven days, newest first. Above the list:

a search for part of a user name, route or target id,
the period (24 hours, 7 days, 30 days, everything),
the area - the list offers the areas that occur,
the method and the result,
the server connection, when there is more than one.

Reset filters clears them all. The list is paged by the server, 25, 50, 100 or 200 entries at a time. On a narrow screen the table scrolls sideways inside its frame.

The address

The address is the one the backend works out from the proxy in front of it. Behind a reverse proxy that is not set up right, every row shows the proxy instead of the visitor - Settings → Network checks it, and Deployment explains TRUST_PROXY.

The address can be switched off on the page's Settings tab. That applies to new rows; the ones stored keep theirs, and a row without one shows "not recorded".

A copy in the TeamSpeak server log

Off by default. Switched on, every successful change on a TeamSpeak server also leaves a line in that server's own log, [TS6 Manager] <user>: <method> <route> - the same form the Query Console uses - so an admin reading the log in TeamSpeak sees which web user was behind the shared query identity. Changes that do not touch a TeamSpeak server (users, the app's settings) have no server to write to.

Each line is one extra query to the server, which counts against its flood limits; the row in the list shows Also noted in the TeamSpeak server log when it went through. If the query identity may not write to the log, the change still happens and only the mark is missing.

Keeping it

The Settings tab of the page:

Record changes - the master switch. Off, nothing new is written; what is stored stays until it is pruned or cleared.
Store the web user's address - on by default, see above.
Also write to the TeamSpeak server log - off by default, see above.
Keep for (days) - 30 by default, 1 to 365.
Keep at most (entries) - 100 000 by default, 1 000 to 1 000 000. Beyond it the oldest entries go first, whatever their age.
The log is pruned every hour, once at start, and at once when you save the settings.
Clear log deletes everything after a confirmation; the page says how many entries are stored and how old the oldest is. Clearing is itself recorded, as the first row of the new log, and so is every change to these settings.

Addresses, and who changed what, are personal data in many places, so how long to keep them is your decision. This page is not legal advice; Privacy and Hosting lists what the app stores.

v0.4, last edited 28.10.2026