Permissions, hierarchy, and scope
The prefix commands.warn, .warns, .delwarn, and .clearwarns are available only in a server and require Moderate Members. Examples use the default . prefix; replace it if the server has configured another. Registered slash versions declare that as their default permission; .warn, /warn, and /clearwarns also validate the target. When creating or removing a warning, Headless rejects the server owner, the bot itself, and members whose top role is not below the bot’s or moderator’s top role (except an owner bypass). The read-only .warns and /warns queries do not run the target-hierarchy check. Records are separated by server and member.
Create a warning
.warn <member> [reason] and /warn create an active warning with a short ID, save moderator, reason, and timestamp, create a moderation case, and generate an entry for the configured Logs flow. The default reason is No reason provided if omitted. Headless attempts to DM the member; closed DMs or a send failure do not roll back the record. The prefix alias is .w.
.warn
.w @member Optional reason
/warn
Review history
.warns <member> and /warns show status, ID, date, reason, and moderator for up to the 20 most recent entries, along with the active count. .warnings and .wl are prefix aliases. With no records, the bot reports that the member has no warnings. Listing does not change the history.
.warns
.warnings @member
/warns
Remove one or all
.delwarn <member> <id> [reason] (prefix aliases .removewarn and .dw) marks a matching ID as removed; ID matching is case-insensitive. It stores who removed it, when, and why, creates a case, and logs the action. There is no slash /delwarn. /clearwarns and .clearwarns <member> [reason] (prefix alias .cw) remove every active warning for that member, save the same removal metadata, and create a case even if none were active. The optional reason defaults to No reason provided.
.delwarn
.clearwarns
/clearwarns
Important behavior
These actions change status; they do not delete history rows.delwarn accepts a matching ID even if it was already removed and overwrites its removal metadata; check the active/removed state in .warns before repeating it. clearwarns runs immediately without a confirmation prompt. There are no automatic punishments or warning-count thresholds for timeout, kick, or ban.
Steps
1
Check the server and permission
Run the command in the intended server and confirm
Moderate Members; for record changes, also confirm the target is within the allowed role hierarchy.2
Record useful context
Use
.warn @member <reason> with a reason that helps staff. The reason is optional, but including it is recommended.3
Review before removing
Run
.warns @member, identify the ID, and confirm the warning is active. For clearwarns, verify the member carefully because there is no confirmation prompt.4
Verify the result
Check
.warns again and review the case or Logs if configured; DM delivery can fail without cancelling the warning.Help and troubleshooting
The command cannot find the member
The command cannot find the member
Confirm the member is in this server and use a mention, name, or ID Headless can resolve. Warning commands do not operate on users outside that server.
The warning ID is not found
The warning ID is not found
Copy the complete ID displayed by
.warns for that member. Matching is case-insensitive, but the ID must still match the stored value.The warning was saved but the DM did not arrive
The warning was saved but the DM did not arrive
DM delivery is attempted after the warning and case are saved. The member may have server DMs disabled or Discord may reject the send; check history, the case, and Logs instead of repeating
.warn.Can I configure a punishment after three warnings?
Can I configure a punishment after three warnings?
No. The current runtime records and removes warnings but does not implement count-based automatic escalation.
