Discord Ticket Bot Audit Log: Every Change, and Who Made It

A staff role that could close tickets last week cannot close them today, and nobody remembers touching it. A panel that was posting fine on Monday is unpublished on Tuesday. A member is asking why their ticket vanished four minutes after they opened it. None of these is a mystery, and none of them needs anyone to own up. They are rows.

Every Discord ticket bot that more than one person administers needs a record of who changed what, and most of them keep something. This is what ours keeps, what it deliberately does not, and how to find one event inside a year of them.

What the audit log records, and what it costs

Anything that changes the state of your server writes one row.

More than seventy distinct actions are recorded, and the short version is that if it changed something, it is in there: a ticket's whole lifecycle, every panel setting down to the working hours and the bot messages, staff roles, blacklist entries, the saved reply library, the widget key, the AI's model and memory, and every billing event.

That list is not something we hardcoded into the website. The dashboard asks the bot which actions exist and builds its filters from the answer, so an action that shipped this month is labelled correctly in your log the same week instead of falling into an unnamed bucket.

Why nothing anyone said is in it

This is the part that surprises people, and it is a decision rather than an omission.

Sending a message is not audited. Not a staff reply typed in Discord, not one sent from the dashboard, not a saved reply. The message already exists in two places, in the ticket channel and in the transcript built when the ticket closes. A third copy inside an accountability record would bury every real change under hundreds of routine ones, and the day you need the audit log is the day you cannot afford to scroll.

The rule underneath it is narrow and worth holding onto. The audit log answers who changed the system. The transcript answers what was said.

Saved replies show the line cleanly. Adding, editing or deleting one is recorded, because your reply library is configuration the whole team inherits. Using one is not, because that is a person answering a ticket.

One thing that looks like a contradiction follows the same logic. Exporting tickets is recorded, and the row says how many of the exported tickets came with their conversations attached. An export is not a message. It is a copy of the record leaving the building, which is exactly the sort of event a record exists to note.

Anonymity does not reach it either. A staff member replying under the shared Staff label is anonymous to the member reading the ticket and is named as themselves in every audit row they generate. Anonymous replies hide a person from the member, never from you.

The ten kinds of change it groups by

Every row carries one category, and the filter is built from them.

Staff rows are worth calling out, because they read as a difference rather than a snapshot. When a role's permissions change, the row says what was granted, what was taken away, and what the role holds now. There are fourteen separate staff permissions, and at that number a row saying "updated staff role permissions" would tell you nothing on its own. If you are working out who should hold what in the first place, our piece on support team structure covers the permissions themselves.

One row for every close, and nine reasons inside it

Closes used to be recorded as five separate actions named after the code path that reached them. One of those names was actively wrong: the row that said an admin had force closed a ticket was written by the inactivity sweep, with no admin anywhere near it. In August 2026 they were collapsed into a single action and the historical rows were rewritten, so nothing in your log reads as a code that no longer exists.

A close is now one row carrying two independent answers. Who closed it, which is a person or the bot. And why, which is one of nine fixed reasons: somebody closed it by hand, the opener closed their own, the AI closed it, the inactivity timer ran out, a close request expired unanswered, the opener left the server, the panel or category it belonged to was deleted, its channel was deleted out from under the bot, or the opener was blocked while it was still open.

The free text reason beside them is whatever the closer typed: worth reading, not worth counting. Sometimes a person wrote it, sometimes the bot did, and on a server running in another language it is in that language. The nine reasons are the stable half. Our guide to closing a ticket reads the same rows from the other end.

Narrowing a year of events down to one

That last step is the one that catches people. There is no server side text search over the audit log, so the search box narrows the page rather than asking for more. When it finds nothing it offers to load older events, and that is the right sequence: widen the window, load, then search.

Every filter lives in the page address, so a narrowed view is a link. "Everything this person did in the last ninety days" is a URL you can keep or send to yourself.

There is also a Download button, which writes the loaded rows to a CSV with the time, the actor, the action, a plain summary and the details. Payment and charge identifiers are stripped on the way out, because a spreadsheet leaving the dashboard carries a different risk from a page inside it.

What is stripped out before you see it

Your audit log is filtered, and it is fair to know what is removed and why.

Actions that belong to us rather than to your server never reach it: the bot joining or leaving, our AI infrastructure being provisioned or moved, a plan limit we rewrote by hand for an enterprise agreement. Those carry your server's ID and no meaning you could act on, and your billing history already shows the outcome.

One event people assume is hidden is not. An admin wiping the AI's memory used to be filed with our infrastructure, which meant the single most destructive thing an admin can do to their own AI was invisible in their own log. It now reads as "Wiped the AI's memory", in your log, with the name against it.

Where the audit log is the wrong tool

Two of those deserve a sentence.

The Manage Server gate is the one teams trip over. Your staff generate most of the rows and cannot read any of them, and there is no permission that grants the audit log on its own. If the thing you actually wanted was ticket activity visible to your team, log channels post opens, claims, closes and transfers into a Discord channel you nominate, free, and they are better at that job than a web page nobody on your staff can open.

The year is a hard edge and not a soft one. Rows are deleted, not compressed or moved somewhere colder, so a compliance question that reaches back further than twelve months cannot be answered from here at all. If your server needs a longer record, the CSV download is the only way to keep one, and it has to be taken before the rows expire rather than after. Removing the bot from a server does the same thing faster: everything tied to that server, audit rows included, is deleted within 48 hours.