# How to set up Discord server logging > Which events are worth logging, how to route them without creating 148 channels, and why Discord's own audit log is not a substitute for this. - Canonical: https://discordguides.blog/blog/set-up-discord-logging - Published: 2026-08-31 - Author: The Manual desk - Facts checked: 2026-08-31 - Sources: - Vetox docs — Logs (https://docs.vetox.io/en/moderation/logs) — checked 2026-08-31 - Discord developer docs — Audit log (https://docs.discord.com/developers/resources/audit-log) — checked 2026-08-31 - Carl-bot — Logging (https://docs.carl.gg/logging.md) — checked 2026-08-31 - Publication: The Manual, an independent site not affiliated with Discord Inc. --- Discord's own record of what happened in your server is thin. Its audit log entries are kept for a finite window, and it does not record message edits, deletions or reactions at all — so a dispute about what someone said three months ago has nothing behind it once the message is gone. A logging bot fixes this by writing a durable, readable record into channels your staff already watch, and the only real design decision is **which events earn a channel and which would just be noise.** **Before you start:** you need **Manage Server**. The bot needs **Manage Webhooks** in each target channel (most logging bots deliver through a webhook they create themselves), plus **View Audit Log** if you want entries to show who performed an action rather than just what happened. ## 1. Turn on the logging module Like most Discord bot systems, this sits behind a master toggle that is off by default on the Setup page. Every event you enable below stays silent until this is on — worth confirming first, since a correctly configured event that never fires almost always traces back to this switch. ## 2. Start with moderation and server-change events, not everything The instinct is to enable every available event on day one. Resist it. A channel that logs every reaction added and removed, every voice channel join and leave, and every message edit across a busy server becomes unreadable within a day, and an unreadable log gets muted by the people who were supposed to be reading it. Start with two categories: - **Moderation** — bans, kicks, timeouts, mutes, role grants and removals, nickname changes. This is the category your team will actually reference during a dispute. - **Server** — name, icon and setting changes, ownership transfers, boost level changes. Low volume, high value: these rarely fire, and when they do, you want to know. Point both at one staff-only channel to begin with. You can split categories into separate channels later once you know which ones actually generate traffic worth separating. ## 3. Add message logging, with an exclusion for your busiest channel Message delete and edit events are the ones people ask for first and regret enabling everywhere. They generate the most volume of any category on an active server, and most of that volume is routine — someone fixing a typo, someone deleting their own message. If your logging tool supports a **per-channel exclusion** specifically on message events, use it on your busiest general or off-topic channel. That keeps the log useful for the channels where a deleted message is actually worth knowing about, without your log channel becoming a mirror of your loudest channel. ## 4. Route by webhook where the channel might move A logging bot normally posts by finding or creating its own webhook in the target channel. Where your tool offers a **webhook URL** as an alternative destination instead of a channel ID, use it for anything you consider critical. A webhook keeps delivering to the same destination even if the channel gets renamed or moved into a different category — a plain channel-based log has to be re-pointed by hand when that happens. ## 5. Turn on executor detail if it is available The difference between "a message was deleted" and "a message was deleted by this specific moderator" is the difference between a log and an actual audit trail. Bots that offer this read it from Discord's own audit log within a short window after the event, which means the bot needs **View Audit Log** — without it, executor detail silently falls back to showing nothing. ## 6. Bulk-create channels instead of toggling events one at a time If your platform supports it, use a **category-mode bulk setup**: it creates one channel per event category under a dedicated logs category, denies `@everyone` from seeing any of them, and grants access only to the staff roles you name. This is the fastest path from zero to a working log structure, and it avoids the alternative — creating up to a hundred-plus individual channels by hand, one per event, which nobody actually wants. ## 7. Give staff a channel reshuffle test Once logging is live, rename or move one of the channels you are NOT logging into, and confirm nothing breaks for the channels you are. Then post a test message and delete it, and confirm the deletion shows up with the right colour and, if enabled, the right executor. This is a five-minute check that catches a missing permission before it matters. ## Vetox's logging system, in depth Vetox tracks **148 distinct Discord events** across 14 named categories — server changes, moderation, messages, channels, roles, emoji and stickers, voice, threads, scheduled events, AutoMod, stage channels, webhooks, integrations, and giveaways — plus four Battle Pass events reachable from the "all events" view. Every one of the 148 can be independently enabled, pointed at its own channel **or** its own webhook, and given its own embed accent colour, and the whole set is free on the **Starter** tier with no cap on how many you enable. What sits behind the $4.99/month **Basic** plan is not the events themselves but three refinements: showing **who did it** by resolving the action against Discord's audit log, delivering to a **webhook** instead of only a channel, and the **category-mode bulk setup** described in step 6 that builds an entire channel structure in one pass. Everything else — every category, every per-channel exclusion on message events, every colour — is identical on every tier. ## How other logging tools compare Logging tends to be one of the stronger free-tier features across this category rather than a paywalled one, and it is worth being fair about that. [Carl-bot](https://docs.carl.gg/logging.md) ships a genuinely comprehensive log — roughly two dozen event types covering message deletes, edits and purges, member role and profile changes, joins and leaves, channel and role lifecycle, emoji, server changes and voice movement — with no premium gate and no documented retention limit anywhere in its module. It is one of the better arguments for Carl-bot in this category, and worth crediting directly rather than working around. Dyno covers moderation-adjacent logging through its automod and moderation modules, with additional logging channels and custom automod responses arriving on its paid Standard tier and above. Set against roughly two dozen free event types elsewhere in this category, Vetox's 148 — spanning categories most general bots do not log at all, like scheduled events, stage channels, webhooks and integrations — is a difference in breadth worth knowing before you assume "logging" means the same thing everywhere. ## Common questions **Why does my log channel show nothing for an event I enabled?** Confirm the master logging toggle on Setup is on, and confirm the event itself is both enabled and pointed at a channel or webhook — an event can be individually enabled while still missing a destination. **Can I log to a channel and get a DM at the same time?** Most logging systems, Vetox included, are channel- or webhook-only for this feature. A DM-style alert is usually a separate mechanism, if the platform offers one at all — check what your specific alert or reminder feature does instead of assuming logging covers it. **How long does the log actually last, compared to Discord's own audit log?** Discord retains audit log entries for 45 days and covers actions, not message content. A bot-based log has no such expiry built in and does cover message edits and deletions, which is the entire reason to run one. **Should executor detail be on for every event?** Turn it on for moderation and server-change events, where knowing who acted matters. It adds little value on high-volume categories like voice movement, where the point is usually the pattern, not the individual.