Safety foundations
Auto-Kick Guardrails that prioritize trust
CleanerBot keeps Auto-Kick predictable by default: confirmations, Safe Mode, and throughput caps prevent accidental or malicious mass removals while keeping staff fully informed.
Why these guardrails exist
Auto-Kick is powerful. Guardrails ensure it stays safe even if someone misconfigures thresholds, clicks too fast, or an admin account is compromised. The aim is to protect guilds from abuse without hiding what the bot is doing.
Misuse resistance
Confirmations and eligibility checks block risky actions before they run.
Blast-radius control
Caps limit how many members can be removed in one window.
Transparency first
Staff are notified of blocks, pauses, and confirmations in real time.
When guardrails trigger
- Most guardrails apply when Auto-Kick is enabled or when inactivity/decay settings change while Auto-Kick is on.
- Throughput caps apply during each Auto-Kick run to limit output and prevent sudden mass removals.
- Safe Mode applies when impact estimates are unavailable, keeping automation conservative until clarity returns.
The confirmation flow
- Enable Auto-Kick triggers a pending state: 24h cooldown, then manual confirm.
- If nobody confirms, the pending request expires after 7 days and Auto-Kick stays off.
- High-risk changes re-enter the pending flow to prevent silent escalation.
Safety layers in practice
Safe Mode for unclear impact
If CleanerBot cannot estimate how many members would be affected (for example, while cache data is rebuilding), Auto-Kick runs in Safe Mode with tiny caps until impact is known. This keeps automation cautious when context is missing.
Throughput caps and manual review
Auto-Kick caps are enforced per run, per hour, and per day, scaling conservatively with managed member counts. When a cap is hit, Auto-Kick pauses and remaining cases are routed to manual review so staff can react before further removals occur.
Two-person approval for larger guilds
Guilds with 100+ managed members require two eligible admins to confirm high-risk actions tied to Auto-Kick and inactivity/decay changes. If only one eligible admin exists, a delayed re-confirm is required.
Strict eligibility checks
Confirmation and configuration require Server Owner, Administrator, or the configured CleanerBot admin role. Eligibility is verified at action time, so a user who loses privileges mid-flow cannot complete the action.
Rate-limit abuse signals, not transparency
Critical toggles are rate-limited to block suspicious spam, but staff still receive a notice for each blocked attempt that includes who tried it, what changed, why it was blocked, and the remaining cooldown.
Operational expectations
These guardrails do not remove staff control. They add friction only where necessary, so admins can catch mistakes early and keep trust with members.
What stays the same
- Manual review queues remain available for edge cases.
- Staff visibility increases rather than being hidden.
- Auto-Kick can still be enabled once confirmations are complete.
What changes
- Activation includes a pending state with explicit confirmation.
- Caps and Safe Mode throttle automation when risk is elevated.
- High-risk changes require more than one eligible admin in larger guilds.
If you want predictable removals with time to react, rely on the guardrails and review caps before making high-impact changes.
Need a community-specific setup? Explore the Use Case Guides.