Wiki / Core Features / Audit Log

Audit Log

Updated by Maxime_48 · 1 week ago · 63 views

The Audit Log records what people do inside the YAWBDB panel — who enabled a feature, changed a setting, added a team member, or what a platform admin did in the backoffice. It is your trail of accountability for everything that happens in the dashboard.

Not the same as Server Logs. Server Logs records Discord events (joins, message deletes, voice activity…). The Audit Log records panel actions (configuration changes, team management, moderation). They answer different questions: "what happened on my Discord server?" vs "who changed what in my dashboard?".


🔭 Three views, one trail

The Audit Log is the same trail viewed at three scopes. An action automatically appears in every view it's relevant to — you never have to look in more than one place.

View Where Shows
Server activity A server → Audit Log Everything done to that server's configuration
Team activity Team settings → Activity Log All governance of the team and everything done on every server the team owns
Backoffice (admins) Admin → Audit Log Every action across the whole platform, all teams and servers

Because the views are interconnected, a single action shows up wherever it matters at once. Enabling a feature on a server appears in that server's log, in its team's log, and in the backoffice. When a platform admin acts on one of your servers, you see it in your own team and server logs too — clearly tagged ADMIN — so backoffice intervention is never invisible to you.


👁️ Who can see what

  • Server & Team activity — the team owner and members with management rights (Administrator role). Members without management rights can't open it.
  • Backoffice — platform administrators only. They see the full, unfiltered trail.

📋 What gets recorded

Server configuration

  • Features enabled or disabled
  • Feature settings saved (Automod, Join Verification, Starboard, Server Logs, and the rest)
  • A server removed from the team

Team governance

  • Members invited, added, removed, or leaving
  • Team renamed or deleted

Backoffice (admin) actions

  • A user banned, unbanned, or given a new platform role
  • Platform SEO settings and integration credentials updated
  • A mailing sent, an announcement published or resent
  • A plan's price changed or synced to PayPal, a feature moved in or out of beta
  • The bot status rotation rewritten, a wiki section deleted
  • The cleanup that deletes every guild the bot is no longer in

Moderation — decisions taken about a person

  • A member sanctioned, the reason rewritten, a history cleared
  • An application accepted or rejected, its answers deleted
  • A report closed, or a sanction issued straight from one
  • An appeal ruled on; a ticket closed or deleted
  • Someone's XP adjusted or reset, a member removed from the birthday list, a suggestion ruled on

Server features, created, rewritten and deleted

  • Automod rules, custom commands, embed templates, giveaways
  • Reaction-role messages, scheduled messages, social alerts
  • Birthdays, suggestions, the leveling settings and its reward graph

Each entry captures who did it (kept even if their account is later deleted), when, and the affected item.

Why moderation is its own category. A decision taken about a person does not belong in the same list as a colour picker. Sanctions, cleared histories, rejected applications and adjusted XP all sit apart from settings changes, so a server owner can read one without wading through the other.

The gap this closed. Moderation used to leave its trail in the Discord log channel — which is optional. On a server without one, clearing a member's history left nothing at all behind. And sanctioning straight from a report bypassed the moderation page entirely: it was the one sanction with no panel-side trace of any kind.

Deliberately not recorded

  • Staff replies and internal notes — they are already durable records carrying their author; auditing them would copy every message into a second table for nothing.
  • Reordering plans, wiki sections or wiki pages — it moves a sort column and nothing else.
  • The body of a wiki page — already archived version by version, with its author.
  • What an AI memory entry said. The trail records that a fact was written, edited or deleted — never its content. The trail outlives the fact and is pruned on its own schedule, so copying the sentence into it would quietly undo the delete.

🔍 What exactly changed

Most entries carry a before / after table: not just "Wordle settings saved", but the fields that moved and what they moved from and to.

Field Before After
channel_id 8412… 9930…
cooldown_seconds 10 30

Open Details on any entry to see it. A few things are worth knowing about how it's built:

  • Only what actually moved is listed. Saving a form without touching anything records nothing, and a field that came back from the form in a different shape — "1" instead of 1 — isn't reported as a change.
  • Lists are compared whole. Adding one channel to an allow-list reads as one change to that list, not as every entry shifting position.
  • Nested settings read as a path, so categories.voice.enabled tells you which category you turned off.
  • Credentials are never written down. If a token or a secret is changed, the entry records that it was rotated — both sides show ••••••••. This applies everywhere, including admin integration credentials.

🎚️ Finding an entry

The same filters are available in all three views:

  • Search — actor, action, description or the affected item
  • Category — feature, server, team, member, subscription, billing, admin, auth
  • Action — the exact action, picked from what actually exists in your log
  • Actor — one person
  • Date range — from / to
  • Server (team and backoffice views) and Source: admin or user (backoffice only)

Active filters appear as chips above the table — click one to remove it. Counters above the filters show the total, the last 24 hours, how many backoffice actions there were, and how many different people acted.


🪝 Push it to your own server

The team trail does not have to be read on this page. Team settings → Webhooks points it at a URL you own: every entry you subscribe to arrives as a signed JSON POST, the moment it is written.

A webhook carries exactly what this page shows and nothing more — same rows, same fields, minus the IP address, which never leaves the panel. Full setup, payload shape and signature verification: Outgoing Webhooks.


⏳ Retention

Entries are kept for a rolling window (180 days by default) and older ones are pruned automatically. The trail is append-only — entries are never edited after the fact.