Telegram night mode: close a group overnight and reopen it safely
Set up Defendy night mode with the right starting days and UTC offset, test both permission changes, and prepare a safe manual reopening procedure.
The last moderator signs off, but the group keeps talking. You can leave the discussion open, arrange overnight cover, or pause posting until morning. Night mode supports that last option: members can still read the conversation while ordinary posting is restricted.
The real test comes at reopening. A group should regain its previous permissions, including any restrictions that existed before the night began. A confirmation saying the mode is off is only part of that story. This guide covers the whole cycle, from recording the starting state to handling a delayed restoration.
This guide follows the technical close-and-reopen cycle, including permission recovery. If you are still deciding posting hours and team availability, start with schedule planning.
Decide whether closing is appropriate
An overnight pause can suit a local community, a class, or a support group whose members share roughly the same working hours. It is less straightforward for an international group: one moderator's night may be a member's only useful time to participate.
Before changing permissions, decide whether you need to prevent posting or simply set expectations about replies. Publishing moderator hours may be enough. If the group does need to close, provide a genuine alternative for urgent matters and explain when it is monitored. A contact nobody checks should not be described as round-the-clock support.
Keep content policy separate. Advertising, repeated messages and newcomer checks still need their own settings when the group opens. Night mode is not a promise of spam-free discussion.
What night mode changes
Telegram provides group-wide permissions that can restrict ordinary members' messages or particular content types. Defendy applies a scheduled restriction and keeps the previous permission state for restoration.
The current night-mode policy restricts text, media, polls, reactions and member invitations. It does not delete the group or its history, individually ban every member, or manage Telegram's slow mode.
Use an ordinary member account to test it. Telegram's ChatPermissions describe non-administrator permissions; an administrator can give you a misleading result. The test account should also have no individual mute or configured boost-based exception.
Record the permissions you want back
Before enabling anything, open the group's permissions in Telegram and record the existing choices. Perhaps text and photos are allowed, while voice messages and invitations are already disabled. That is the state you want after reopening. Turning every option on would quietly change the group's policy.
Choose who will supervise the first cycle and who can reopen the group manually. During that test, avoid having another bot or administrator change the same default permissions. Competing changes make the result hard to diagnose, and a delayed restoration can overwrite a manual adjustment.
Check Defendy's administrative access. For a new night-mode cycle, the current implementation checks permissions to change group information, invite, pin and restrict members. Topic-management access is required when that permission is enabled in the saved state. Address the specific missing right reported by the bot. Promoting administrators and deleting messages are not part of this night-mode admission check.
Configure the first window
- Open @defendy_bot, choose Settings, and select the group. Use a separate test group for your first attempt.
- Open General settings and check Group timezone. Your phone's clock is not proof of the group's saved setting.
- Open Night mode. Check the existing interval before enabling it: if the current time falls inside that interval, restrictions can begin applying.
- Enable the module, set Start and End, and choose the days of the week. The current Mini App edits one recurring window.
- Reopen the page to confirm the saved values. Toggles and valid window edits save when changed; this form does not require a separate general Save step.
Start and End must differ. A 23:00–07:00 window crosses midnight; a 09:00–18:00 window restricts posting during the day. Enter the hours when posting should be blocked, not the hours when you want it open.
Select the day the window begins
With Friday selected and a 23:00–07:00 interval, the group closes on Friday evening and reopens on Saturday morning. Selecting Saturday is not necessary to complete that first night. It adds a second night, from Saturday into Sunday.
| Selected days | Restriction starts | Restriction ends |
|---|---|---|
| Friday | Friday at 23:00 | Saturday at 07:00 |
| Saturday and Sunday | Saturday and Sunday at 23:00 | Sunday and Monday at 07:00 |
| All days | Every evening at 23:00 | Each following morning at 07:00 |
Treat the time zone as a fixed UTC offset
The Mini App offers whole-hour offsets from UTC−12 to UTC+12. A city name beside an option is a selection aid, not an automatic daylight-saving rule. If the region changes its clocks, review and adjust the saved offset yourself.
Half-hour and quarter-hour zones cannot be selected exactly in this list. Do not assume rounding to the nearest entry is harmless. If using a supported offset as a reference, convert the restriction times deliberately and check whether the starting day changes. The group-hours planning guide covers the wider scheduling decision.
Test a complete close-and-reopen cycle
Schedule the first trial while an administrator is available. In a test group, choose a convenient upcoming interval and remain available until it ends. The steps below are a test plan, not a report of a live group already tested.
Before the window, have the ordinary member send a short text and one permitted media type. After the start, confirm that posting is restricted. After the end, repeat the original actions and compare the group's permissions with your record. Anything forbidden before the test should still be forbidden afterward.
The scheduler runs periodically, and Telegram must complete the permission change. Do not treat this as a second-precise timing guarantee. Record the observed time and state at both transitions. A saved toggle, command acknowledgement, or event saying a change was requested does not establish that the group actually closed or reopened.
If individual mutes matter to your workflow, include one in the test plan. Restoring group-wide permissions is not an instruction to remove a member's separate mute.
Reopen early without losing track of tomorrow
An administrator with the required authority can disable the module in settings or send /nightmode off. The command persists the disabled state and requests restoration of the previous permissions. It does not skip just one night: the schedule will remain off tomorrow unless someone enables it again.
Check the actual permissions and have the ordinary member try posting after the command. A reply that restoration was requested is not proof that restoration finished. When returning to the regular schedule, check whether the current time is already inside the saved window before enabling it.
If restoration is delayed and the group must open, an authorized administrator can manually return the permissions to the recorded baseline in Telegram. Coordinate this carefully: Defendy's pending restoration can still change permissions later. Recheck the resulting state and leave scheduling disabled until the problem is understood.
Troubleshoot the observed failure
- Check the selected group, saved days, interval and UTC offset. An unexpected result after midnight often points to the starting-day choice.
- Confirm that Defendy is still an administrator with the required rights. After a missing-permission refusal, also check whether the module remains enabled.
- Use the ordinary test member. Admin privileges, an individual mute or an exception can distort the result.
- Record the time, error text and actual Telegram permissions. If logging is configured, compare its events with the observed effect.
- Look for another bot or administrator changing the same permissions. Repeatedly sending the same command rarely clarifies an uncertain state.
A successful night ends with the group usable again, its original restrictions intact, and the team knowing how to recover if needed. See the night-mode reference for the current controls and defaults.
Reviewed on 5 October 2026 against Defendy's current interface and implementation. The scheduler is implemented; your production group still needs its own supervised test.
