Moderation Log and history
Review chronological moderation records with source, action, actor, date, case, and severity filters.
- Audience
- moderator · senior reviewer · team lead
- Availability
- free · private beta access
- Maturity
- alpha · partial
Last reviewed
On this page
Find the authoritative moderation record
The Moderation Log combines server-scoped moderation actions, imported moderation, jail history, and staff notes into a chronological view. Routine member, voice, message-metadata, role, channel, and server activity belongs in Activity instead of flooding moderation history.
Set the server, member, and time range
Record listing requires dashboard access and the effective record permission. Linked cases, evidence, notes, and exports are rechecked separately.
Open Moderation Log in the selected server dashboard and begin with a narrow member, action, date, source, actor, case, or severity filter.
- A server-scoped moderation question such as who acted, which punishment occurred, or which case is involved.
- A reliable member, actor, date range, source, or action clue.
- Permission for any linked detail you plan to open.
Trace an action through history
Narrow the record set
Apply the most specific known filters and keep source badges visible.
Check: The table returns a manageable chronological result.
Read attribution and source
Check actor, target, action type, timestamp, source, case link, and severity where present.
Check: Staff do not mistake an imported provider for the actor or routine activity for a moderation action.
Open the underlying record
Follow the supported case or detail link when the decision requires more context.
Check: The linked surface performs its own visibility check.
Record the conclusion
Use a case or staff handoff for follow-up instead of editing history to fit the conclusion.
Check: The original chronological record remains intact.
History review examples
Authorized staff can reconstruct visible moderation history, distinguish source from actor, and move non-moderation investigation into Activity.
- Filter one actor and date range during a shift review.
- Separate imported moderation from native ModFlow actions by source badge.
- Use an exact legacy activity link only as a compatibility handoff into Activity.
Understand what appears in the Moderation Log
| Family | Examples | Source/identity notes |
|---|---|---|
| Native moderation actions | Warn, mute, duration adjustment, unmute, jail, unjail, ban, unban, undo. | Requested actor and executor can be recorded separately; linked to a server-scoped Case. |
| Case events | Creation, claim, comments, evidence, decision, execution, close/reopen. | Case ID is internal; Case number is human-facing within one server. |
| Appeal events | Submission, review, decision, reversal status. | Public appellant status is narrower than staff detail. |
| Scheduled actions | Pending, executing, executed, failed, cancelled. | The scheduled request and actual execution are different events. |
| Jail history | Active jail, release, paused/rejoin, transcript status. | Role/channel cleanup may be partial. |
| Imported moderation | Normalized warning, mute, ban, or other supported external log. | Provider, actor, source message, confidence, and occurrence time stay distinct. |
| Staff-authored notes | Member context or handoff. | Attributable context, not native source evidence. |
Use filters without hiding the answer
| Filter | Use it for | Check before concluding |
|---|---|---|
| Member/target | One person’s moderation history. | Exact user ID and selected server. |
| Moderator/actor | Actions attributed to one staff member. | Native actor versus provider/system executor. |
| Action type | Warnings, mutes, bans, jails, reversals, or Case events. | Related action names and imported normalization. |
| Date range | Incident window, shift, month, or appeal review. | Occurred-at versus stored/created-at time. |
| Source | Native ModFlow, import provider, staff note, or other supported origin. | Source is not automatically the human actor. |
| Case | Every linked event in one Case lifecycle. | Internal ID versus server-scoped Case number. |
| Severity/status | Prioritizing high-impact or unresolved work. | The meaning is workflow-specific and not a guilt score. |
Start narrow
Use the strongest known identity, date, source, or Case clue.
Check: The result set is readable.
Expand one filter at a time
Remove only the filter most likely to hide the record.
Check: The reason a row appears is understandable.
Open the source record
Follow the Case/detail link rather than relying on a truncated table row.
Check: The full permission-aware state is reviewed.
Reset before another member
Clear filters and confirm the new target/server.
Check: Old filters do not create a false absence.
Audit one moderation action end to end
Find the action
Search by target, actor, action, and occurrence window.
Check: The exact action row is identified.
Check attribution
Read initiator/requester, executor/system actor, source, and reason.
Check: The human and system roles are not conflated.
Open the Case
Review linked evidence, decision, execution, and timeline events.
Check: The action is understood in context.
Compare current state
Check whether the restriction is still active or has been reversed/expired.
Check: Historical action is not mistaken for current state.
Record discrepancies
Use a Case comment, staff note, or admin issue as appropriate; do not rewrite history.
Check: The original record and later correction remain distinguishable.
| Question | Why it matters |
|---|---|
| Who requested the action? | Establishes staff accountability. |
| Who or what executed it? | Distinguishes bot/system execution from human decision. |
| What did Discord actually do? | Separates request from external result. |
| Was the reason sufficient and visible to the correct audience? | Supports review without leaking evidence. |
| What changed later? | Expiry, appeal, reversal, rejoin, and manual correction alter current state. |
Use /modhistory and /modstats responsibly
| Surface | Shows | Does not show/prove |
|---|---|---|
| /modhistory | Recorded action history and basic activity for the selected moderator/server. | A global employment record, a quality ranking, or complete context for every action. |
| /modstats | Aggregate activity over the selected lookback window. | Performance, fairness, policy compliance, or workload difficulty by itself. |
| Staff directory/activity drawer | Visible team membership and basic server-scoped activity where permitted. | Authority beyond live permissions or an approved performance score. |
Account for filters and unavailable sources
Filters reflect stored moderation fields and can miss malformed, deleted, unavailable, or not-yet-imported source material. Use Activity for metadata-only operational events; neither surface is an infallible account of off-platform events.
Something is missing or looks wrong
What you see: The current view does not contain the record, field, source, or output you expected.
What may be happening: Server scope, viewer permission, filters, source availability, feature gates, or stale state can change what the product may show.
What to do
- Clear filters one at a time and confirm the date range.
- Check the source badge, actor label, and selected server.
- Open Activity when the question concerns voice, streaming, member, role, channel, or server changes.
- Document a suspected missing moderation record for an administrator rather than fabricating a replacement.
History and event logs serve different jobs
Canonical moderation history records actions, Cases, decisions, notes, and linked outcomes. Native Discord event logging sends configured operational events to a selected Discord destination and maintains delivery state. Imported records retain their source provenance and do not become native observations merely because they appear in one timeline.