Automatic Telegram bans: design an escalation policy you can defend
Decide when a ban belongs in your warning policy, inspect Defendy presets and weighted thresholds, and test both enforcement and recovery before enabling automation.
An automatic ban saves a moderator from having to react to every repeated violation. It also removes the pause in which a moderator might notice that a filter is wrong. A support question mistaken for promotion can move through a punishment ladder just as efficiently as actual spam.
Before enabling bans, decide whether the underlying signal is reliable enough and whether a wrongly restricted member has a way to reach the team. Defendy supports a direct ban as a filter action and a ban reached through warning points. These are different policies. The existence of a warning ladder does not guarantee that members receive several chances before they lose access.
After a ban, the team still needs to manage exceptions and correct mistakes. Follow the blocked-member list procedure when reviewing an individual case.
Decide which cases belong in automation
Write examples of prohibited behavior alongside similar permitted behavior. If moderators cannot agree which category an example belongs to, refine the rule before making its consequence automatic.
Repeated, clearly disallowed promotion may be a candidate for escalating restrictions. Sarcasm, arguments and quotations from an abusive message require more context. For those cases, a temporary pause followed by human review is often easier to justify than assigning a large warning weight to an ambiguous match.
Also agree on the response to a serious single incident. A ladder does not require moderators to wait for more harm before intervening manually. Equally, an automatic ban should not become the default merely because no moderator has had time to investigate a disagreement.
Understand the cost of reversal: Telegram's Bot API ban removes the user's messages in supergroups. Unbanning allows a return but does not rejoin the member automatically. Telegram's ban and unban documentation.
A ladder follows points, not a guaranteed sequence of chances
A filter configured to issue a Warning adds its selected weight. Defendy compares the total with the configured thresholds and selects the highest eligible tier, taking account of actions already applied. The points, threshold and punishment type are separate choices.
Suppose a member already has one point and the next event adds five. The total reaches six immediately. A higher tier can apply without the member first serving every lower restriction. Further points can also cause the last configured action to run again.
Here is a hypothetical policy for discussion, not a built-in preset:
- Two points: a 15-minute mute.
- Four points: a two-hour mute.
- Six points: a one-day ban.
- Counter window: 24 hours from the first point addition.
With a weight of one, the final tier requires six points from six events. With a weight of three, two events can reach it. Raising the weight of a filter is therefore a consequential policy change, even if none of the tier thresholds moves.
Consider the relationship between the two clocks, too. If a restriction lasts longer than the accounting window, the points may have expired before the member returns. That might be an intentional fresh start, but it is incompatible with promising a permanent record of strikes. The warning points guide explains the reset window in detail.
Read every tier in a preset
In the Mini App, open Settings → My groups → your group → Warnings. The mode selector provides basic single-threshold behavior, ready-made profiles and custom tiers.
The current ready-made profiles contain these actions:
| Profile | Earlier tiers | Final tier |
|---|---|---|
| Mild | Three points: one-hour mute | Five points: one-day ban |
| Moderate | Two points: one-hour mute; four: one-day mute | Six points: indefinite ban |
| Strict | One point: 30-minute mute; three: one-day mute | Five points: indefinite ban |
“Mild” names a specific configuration; it does not mean “no bans.” Selecting a preset replaces the tiers and saves the change. Inspect alternatives in a test group rather than clicking through them in a live community.
There is another consequential shortcut: Add tier from basic mode creates a second tier two points above the current limit, with an indefinite ban. It is not simply a button that reveals an empty form. Inspect every new row before proceeding.
Build a custom policy in a safe order
First write down the intended threshold, action and duration for each tier, plus the weight of every participating filter. Name the moderator who will handle appeals and make sure someone can reverse restrictions. Reproduce that plan in a separate test group before transferring it to a live one.
- Check the selected group and open Warnings.
- Choose custom mode and set the threshold, action and duration of each row. The current tier editor offers thresholds from 1 to 20.
- Keep thresholds distinct. If a value is already used, the editor shifts it to an available value; reread the resulting ladder rather than relying on what you initially selected.
- Reselect the duration whenever you change the action. The shared punishment selector resets duration to zero. For warning mutes and bans, zero means indefinite; the None action is the separate way to configure no punishment at a tier.
- Set the counter reset period, wait for the saved confirmation and reopen the section to inspect the actual values.
- Connect the intended filters by selecting Warning and their weights. A filter still configured for a direct ban will not wait for warning points.
Switching back to basic mode does not disable warnings; it leaves a single threshold active. To stop an incorrect automatic trigger, correct or disable the relevant filter. When changing policy in a live group, coordinate a pause with the moderation team instead of experimenting while real triggers continue to arrive.
Test transitions, including recovery
Use harmless test text, a consenting ordinary member and a group without valuable message history. Keep a record of the original settings. Configure selected-event logging, then verify that a control event actually reaches the destination.
The minimum test plan should cover:
- An addition below the first threshold, with no unexpected restriction.
- Exact arrival at each threshold, checking the selected action and duration.
- A high-weight event that jumps over a tier.
- A further addition after the final tier, rather than assuming it is harmless.
- Correction of points separately from removal of the restriction.
- Reopening the settings after a preset, action or duration change.
Start each independent scenario with the appropriate clean counter and no leftover restriction. A muted account cannot send the next test message until its restriction ends or is explicitly removed. Defendy's minimum temporary mute is 60 seconds. Begin with an ordinary finite duration rather than using an indefinite restriction as a convenient test setting.
If the plan includes a ban, explain the consequences to the tester in advance and avoid an account with important contributions in that group. A successful configuration save is not evidence that the full enforcement and recovery sequence worked. These are proposed checks, not a claim that we ran them in a live community.
Recover from a false-positive ban in the right order
Prevent the same error from immediately happening again. Find the triggering filter and inspect its rule and weight; temporarily disable it if necessary. Restoring membership while leaving a bad trigger active may simply lead to another restriction.
Then work through four separate questions:
- Is this the right person? Verify the original message or a reliable user identifier instead of relying on a display name.
- Which path caused the ban? Compare available context, the event record, current points and configured tier. A direct filter action and a warning threshold can lead to the same visible result.
- Which points should be removed?
/unwarnsubtracts one point./resetwarnsclears the active total. Neither command lifts an existing ban. - Has access been restored? Use
/unbanfor the verified member, explain how to return and check the outcome. A mute has its own recovery command,/unmute.
Do not promise to restore deleted messages. Explain the correction to the member and leave enough context for the next moderator to understand the decision. An appeal should trigger a review of the evidence, not an argument about whether the counter must be right.
A practical go/no-go decision
Enable the policy for its intended scope only when the team understands every weight and threshold, the checks produce the expected outcomes, logging works and a restricted member can appeal outside the group. If one of those is unknown, keep a more cautious policy while closing that gap.
Warning tiers apply to the selected group. They do not create a universal cross-group ban list, an automatic appeal service or a private explanation to every restricted person.
Checked on 5 October 2026 against Defendy's current implementation, the warnings guide, moderation commands and Telegram's linked documentation. Reviewing implementation does not verify that a particular deployed group has applied the policy successfully.
