Tools
Every moderation action, on the record.
The audit log records who did what and when, from bans to channel edits. When a member asks, when moderators disagree, when something changed overnight: the answer is already written down. Accountability built in.
What gets logged.
If it changes the server or affects a member, it leaves a record.
The audit log is the running record of staff activity in your server. It is not a place you configure or a feature you remember to turn on. It is built in, and it records from the moment your server exists. Every entry captures the same four facts: the action, the staff member who took it, the target, and the timestamp.
Owners decide which roles can read the log. Many communities give all moderators access, because a log everyone can see keeps everyone careful. That is the quiet design idea behind the whole feature: a record that staff know exists changes how staff behave, long before anyone ever needs to look something up.
Bans and kicks
The heaviest calls a staff team makes. When someone is removed from your community, the log records who removed them and when, so the decision never rests on one person's memory.
Timeouts
Temporary silences are easy to forget and easy to dispute. Each one lands in the log with the actor and the target, so a week later you can still say exactly what happened.
Staff deletions
When a moderator deletes a message, the log records that it happened. Removal stays a moderation tool, not a way to make an action itself disappear without a trace.
Channel and category changes
Channels created, renamed, moved, or removed. Categories reshuffled. Structure changes shape how your whole community navigates, so they are always on the record.
Role edits
Roles decide who can do what. When a role is created, renamed, or changed, the entry shows which staff member touched it, so power never shifts silently.
Permission changes
The most consequential edits are often the least visible. A permission flipped on a role can change everything about a channel, and the log makes sure you can trace it back.
Anatomy of an entry.
Four facts, every time. Enough to reconstruct any decision, without recording anything that is not the staff's business to record.
Every entry answers
- What happened - the action itself: a ban, a timeout, a deletion, a channel or role change
- Who did it - the staff member who took the action, by name, not by guesswork
- Who or what it affected - the member, message, channel, or role on the receiving end
- When - a timestamp, so actions line up against the conversation that surrounded them
What it never contains
- Your direct messages. DMs are private; we don't read them, so there is nothing for a log to record
- Ordinary conversation. Chatting is not a moderation action; members talking does not create entries
- Anything for anyone else. The log belongs to your server; we never sell data and run no trackers, ads, or data brokers
- Noise. Four facts per entry keeps the log fast to scan, even on a busy day
The four-fact shape is a deliberate trade-off. A log that recorded everything would be a surveillance tool nobody reads; a log that recorded less would leave disputes unresolved. Action, actor, target, timestamp is the minimum that lets you reconstruct any staff decision, and the maximum that respects what moderation is actually for. Community channels are visible to their community and its moderators, precisely so moderators can keep public spaces safe, and the audit log is the accountability side of that same bargain: staff can act in public spaces, and their actions are visible to each other.
Reading it in practice.
Three worked examples of what an entry tells you, and what you do with it.
A member asks why they were timed out
- The entry shows which moderator issued the timeout and the exact minute it landed.
- The timestamp lines the action up against the messages around it, so the context is one scroll away.
- Whoever answers the member quotes the record instead of reconstructing it from memory. The conversation stays short and stays fair.
A channel was renamed and nobody owns up
- The entry names the staff member who made the change and the channel it affected.
- What could have become a round of accusations in staff chat is over in one lookup.
- If the rename was a mistake, you now know exactly who to talk to, and the conversation is about process, not blame.
A permission changed and a channel went quiet
- Members report they suddenly cannot post. The log shows a role edit from Monday evening, with the actor attached.
- Instead of auditing every role by hand, you start from the one that changed. Cross-check it against your roles and permissions setup and fix it in minutes.
- The timestamp tells you how long the misconfiguration existed, which tells you how big the cleanup is.
Notice the pattern: in every case the log turns a question about people into a question about a record. That shift is what keeps staff teams calm. Nobody has to defend their memory, nobody has to accuse a colleague on a hunch, and the member on the other end gets an answer grounded in fact.
Accountability, by design.
The audit log runs on the same infrastructure as everything else we build, so the record is there whenever you reach for it.
Why it matters.
Trust is easier to keep than to rebuild.
When a member asks why they were timed out, the answer is in the log rather than in someone's memory. When two moderators disagree about what happened, the log settles it in seconds. Quiet accountability like this is what keeps staff teams healthy as they grow: the larger the team, the more decisions happen while you are asleep, and the more valuable a shared record becomes.
There is a second, less obvious benefit. A visible log protects good moderators as much as it checks careless ones. When a staff member makes a hard but correct call and the community pushes back, the record shows exactly what they did and when. They do not have to argue their own case from memory; the log does it for them.
The audit log is part of the wider moderation toolkit, alongside slow mode, automated filters, and pinned messages. Here is how experienced owners fold it into their routine:
Decide who reads it
Owners choose which roles can read the log. Our advice: give it to every moderator. A log only the owner sees is an archive; a log the whole team sees is a culture. People act differently, and better, when their actions are visible to their peers.
Review it weekly
The moderation guide suggests making a weekly review of the log a habit. Ten minutes is usually enough: scan the week's actions, spot patterns, and catch anything that deserves a follow-up conversation before it becomes a grievance.
Anchor appeals to entries
When a member disputes a ban or a timeout, start from the entry, not from the argument. Quote what the record says, then discuss whether the call was right. Separating the facts from the judgment keeps appeals civil and short.
Onboard new staff with it
The recent log is the best training material you did not have to write. A new moderator who reads a few weeks of entries learns how your team actually operates: what gets a warning, what gets a timeout, what gets escalated. The owner handbook covers this in more depth.
Memory versus the record.
The same five situations, handled without a log and with one.
None of this requires the log to be dramatic. Most weeks it is the least exciting page in your server, and that is the point: it works by existing, quietly, so the one week you need it, it is already there.
Audit log and message log: two different jobs.
People sometimes conflate them. They answer different questions, and only one of them is live today.
Audit log - available now
- Records staff actions: bans, kicks, timeouts, staff deletions, channel and role changes
- Answers who moderated, and when
- Built into every server, nothing to enable
- Read access controlled by the owner through roles
Bot engine message log - coming soon
- Will record member message edits and deletions to a private staff channel
- Answers what a vanished message said, who wrote it, and when it changed
- Ships as one toggle of the upcoming bot engine, alongside welcome cards, custom commands, and tickets
- Opt-in per server, switched on by the owner when it launches
Together they will cover both halves of the accountability picture: the audit log watches the staff, and the message log watches the messages. If a moderator deletes something, the audit log records the deletion today; once the bot engine ships, the message log will also preserve what the deleted message said, for staff eyes. Until then, the audit log carries the load, and it carries the important half: the actions with power behind them are already on the record. Follow the changelog for the bot engine release.
Questions about the audit log.
Who can read the audit log?
That is the owner's call, made through roles and permissions. Owners decide which roles can read the log. Many communities give all moderators access, because a log everyone can see keeps everyone careful. If you prefer a smaller circle, restrict it to senior staff; the log works either way, but the openness is where most of the cultural benefit comes from.
Do I need to set anything up?
No. The audit log is part of the platform, the same way channels and roles are. It records staff actions from the start; your only decision is which roles get to read it. There is nothing to install, nothing to host, and no third-party logging bot to invite and keep alive.
What exactly does an entry contain?
Four facts: the action, the staff member who took it, the target, and the timestamp. That is enough to reconstruct any moderation decision and line it up against the conversation around it, without turning the log into a surveillance archive that nobody wants to scroll.
Does it record private conversations or member chatter?
No, on both counts. Direct messages are private, so we don't read them and there is nothing for a log to record. And ordinary conversation in channels is not a moderation action: members chatting, reacting, and editing their own thoughts does not create audit entries. The log tracks staff power, not member speech. Read more about how we draw that line on our privacy page.
How is this different from the bot engine's message log?
The audit log is live today and records staff actions: who banned, who deleted, who edited a role. The message log is a feature of the upcoming bot engine: when it ships, it will record member message edits and deletions to a private staff channel, so moderators can see what a vanished message said. Different questions, different tools; the audit log is the one you already have.
A member says their timeout was unfair. What do I do?
Start with the entry. It tells you who issued the timeout and when, which lets you find the surrounding conversation and judge the call on its merits. If the call was right, you can explain it with specifics instead of generalities. If it was wrong, you know exactly which moderator to debrief with. The moderation guide has a fuller playbook for handling appeals.
Does the audit log cost anything?
No. It ships with every server as a core feature, and core features stay free forever, with no surprise paywalls. Accountability is not something we think a community should have to pay extra for.
Your community. Your rules. Your data.
Create a server, invite your people, and see what chat feels like when your account actually belongs to you.
Free to start. Live in under a minute. No install required.