Back to Guides Hub

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.

Invite CleanerBot Explore Features

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 applied 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.

Optional compatibility limit for security bots

Admins can use /config set auto_kick_daily_limit with a value from 1 to 200 when another security or moderation bot needs lower removal throughput. The configured value limits each Auto-Kick run, each fixed UTC hour, and each fixed UTC day. CleanerBot calculates each effective limit as the lower of its built-in guardrail and the configured value, so this setting can lower throughput but can never raise a safety cap.

/config show displays the configured value and the effective per-run, hourly, and daily limits. Use /config remove auto_kick_daily_limit to return to CleanerBot's built-in guardrails.

Two-person approval for larger guilds

Guilds with 100+ tracked 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.

How the compatibility limit is applied

CleanerBot keeps separate built-in limits for one run, one UTC hour, and one UTC day. If a guild configures a compatibility limit, the same configured number is compared with all three built-in limits independently.

Effective per run = lower of built-in per-run limit and configured limit

Effective per hour = lower of built-in hourly limit and configured limit

Effective per day = lower of built-in daily limit and configured limit

For example, if CleanerBot's built-in limits are 30 per run, 60 per hour, and 150 per day, a configured limit of 20 makes all three effective limits 20. A configured value of 200 leaves the built-in limits unchanged.

When any effective limit is reached, remaining eligible members stay pending for manual review and staff receive a notice explaining whether the configured compatibility limit or a built-in guardrail paused Auto-Kick.

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.

Invite CleanerBot Join Support Community