Vetox Logging — capability reference

What it is

Per-event Discord audit logging across 148 distinct event types — the largest event count of the sixteen moderation and security bots checked. Each event is independently enabled, pointed at its own channel or its own webhook, and given its own embed accent colour. On Basic and above, an event can resolve and display the executor from Discord’s audit log. A bulk setup tool creates the channels and wires the events in one pass.

The problem it solves

Discord’s own audit log is retention-limited, unsearchable in practice, and silent on the things staff most often need to reconstruct. It does not cover message edits, message deletions, reactions or voice movement at all.

What a moderation team actually needs is a durable, readable, per-category record in channels they already watch — so that “what happened in voice at 3am” is a matter of scrolling one channel rather than of asking three people what they remember.

How it works

Static definitions with per-server overrides. The 148 events are defined centrally. A server stores only the events it has actually configured, and the two are merged on read. Saving one toggle sends one changed event, not the whole configuration.

Delivery. Every log passes through a single choke point. It requires the Logging module toggle on the Server Setup page, then the event’s own enabled flag, then either a channel or a webhook URL. Where a channel is configured, the bot finds or creates its own webhook there. The message is built from Discord’s component system rather than a legacy embed, so it renders as a structured block with separators and a thumbnail rather than a wall of fields.

Executor detection reads Discord’s audit log within a five-second window after the event, needs View Audit Log, and skips silently when the audit log is unavailable rather than posting a log entry that guesses.

Two destination types, and the choice matters. A webhook URL keeps working when the channel is renamed or moved, and does not require the bot to hold send permission in that channel. A channel ID is simpler and requires no setup outside the dashboard. They are mutually exclusive per event. The mechanics of the underlying delivery are covered in the webhooks reference.

What is configurable

Per event

The 148 events, by category

The seventeen voice events are the ones no native audit log offers, and they are the ones that answer the arguments moderators actually have to adjudicate.

The five AutoMod events log Discord’s own AutoMod — rule lifecycle and action execution — which means the native filter and the bot filter land in one timeline instead of two.

Bulk channel creation

One request creates up to 148 channels, in batches of twenty, either one per event or one per category. Each created channel denies View Channel to @everyone, allows View Channel and Send Messages to the roles you nominate, and denies those roles on any exception channels you name. The resulting channels are wired to their events automatically.

This is the difference between an afternoon of dashboard work and a single form.

Tier availability

There is no event-count limit at any tier. A free server can enable all 148, each with its own channel and colour, and that is the configuration the free tier is meant to support.

Three gates sit at Basic — executor detail, webhook delivery, and the bulk setup tool.

Commands

None. Logging is configured entirely from the dashboard and driven by Discord gateway events.

There is a reason worth stating: a logging system configured by chat commands produces a configuration nobody can audit, because the record of how it was set up scrolls away.

Dashboard surface

• /server/:id/logs — a tab strip of All plus 14 categories, each showing its enabled count, with a search box and a running total.
• /server/:id/setup — the Logging module toggle every log delivery requires.

/server/:id/dashboard-logs is a different system. It renders Dashboard Watcher, the audit trail of actions taken in the dashboard itself. It shares no storage with the 148 event logs and has no per-event configuration.

Permissions required

A webhook URL destination is the exception: it does not require the bot to hold send permission in the destination channel at all, because the webhook carries its own authorisation. See the permissions reference for why that distinction matters.

What it connects to

Logging is the system every other system writes into. That is its whole architectural role.

• Moderation — bans, kicks, timeouts, mutes, role and nickname changes land in the Moderation category whether they came from a slash command or from the Discord client directly.
• Protection posts to its own dedicated log channel as well, so a protection event is never buried in general server noise.
• Anti-Raid actions arrive as ordinary moderation events.
• Giveaways logs arrive over the internal message bus rather than from a gateway event, and render through the same pipeline.
• AI moderation actions appear alongside human ones, so a member’s history is one timeline rather than two.
• Dashboard Watcher records who changed the logging configuration.

The chain: every system → Logging → the channels your staff already watch.

Who it is for

Any server where a moderation decision might be questioned later. That is a smaller set than “every server” and a much larger set than “large servers”.

Specifically: teams big enough that no one person saw everything, communities where appeals happen, servers with a history of insider incidents, and anyone who has tried to reconstruct a deleted message from memory and discovered it cannot be done.

Practical use cases

Separate the noise from the signal. Voice events into a staff-only voice channel, message events into a moderation channel, server and role events into an admin channel. Three destinations, one configuration, and nobody has to read 17 voice-state changes to find a ban.

Colour-code severity. Destructive events in red, routine events in the default blue. A moderator scanning a channel reads colour before they read text, and the accent is per event rather than per category.

Exclude the channels that generate volume without information. The nine Messages events accept an excluded-channel list, so a bot-command channel or a high-traffic memes channel stops flooding the message log without disabling the log.

Stand up the whole thing in one pass. Bulk create in category mode produces 14 channels, private to the roles you name, wired to their events, in one form submission.

How it compares

Logging is the clearest paid axis in the moderation category. Four of the sixteen moderation and security bots examined paywall some or all of it, in four different shapes. None of them paywalls the ban command.

Zeppelin has the second-deepest event coverage found and it is entirely free, which is worth stating plainly. Its 66 log types sit alongside the finest staff-permission model in the category. The obstacle is availability rather than capability: its own documentation says hosted access is granted on a case-by-case basis, and self-hosting is Docker-on-Linux under a source-available licence.

Sapphire’s 80+ types are free at the point that matters most, and its paid axis is branding rather than coverage — a cleaner geometry than paywalling the events themselves.

The two contrasts that survive scrutiny are coverage and where the line falls. On coverage Vetox is the most complete in the category: 148 is the largest event-type count found in this research — ahead of Sapphire’s 80+ and Zeppelin’s 66 — and the free tier includes every one of them with per-event channels and colours. Where competitors charge, they charge for the logs themselves — GiselleBot for the loggers, Beemo for moderation logs, Gaius for the audit stream. The Vetox gates are on executor attribution, webhook delivery and the setup tool, with the event coverage itself ungated.

One genuine caveat: a small server that needs a message-delete log and nothing else is well served by Carl-bot’s free tier and will not notice the difference between 24 events and 148.