Telegram group hours: design a schedule members can actually understand

“Our hours are nine to six” leaves a surprising amount unanswered. Can members leave a question on Saturday? Will the message wait until Monday, be removed, or be impossible to send? Is the group closed, or is the team simply off duty?

Start by answering those questions. Defendy schedules posting restrictions through Night mode, whose current Mini App form edits one recurring window. A clear weekly plan helps you decide whether that window can express the hours you actually want.

This article helps the team agree on its timetable and commitments to members. Once that policy is chosen, use the timed-restriction procedure for rollout and manual fallback.

Separate three different promises#

Posting hours say when members can write. Staffed hours say when someone is reading the group. Response expectations say how long an individual question may wait. These can overlap without being identical.

A software community might accept questions at any time while its moderators work weekdays. Closing it overnight could stop someone from leaving a useful bug report. A class discussion, by contrast, may intentionally run within a supervised session.

Opening the group at 09:00 does not mean every outstanding question will receive an answer at 09:01. State the posting rule and team availability separately. Only publish a response commitment your team has agreed to meet.

Choose a policy before choosing times#

Three common arrangements cover many groups:

• Always open, staffed on a schedule. Members can leave questions and help one another. Publish moderator hours; a posting restriction may be unnecessary.
• The same pause every day. For example, posting closes from 22:00 to 08:00 at one agreed UTC offset. This fits a single recurring restriction window.
• Different weekday, weekend and holiday hours. This needs closer planning. The current form has no holiday calendar or multiple daily intervals.

Telegram supplies group-wide member permissions; Defendy's night mode changes them on a schedule. This is not a separate access system for staff working after hours. The form does not offer schedules for arbitrary roles, and making someone an administrator merely to bypass closing time is a poor substitute for designing the right policy.

Enter closed hours, not opening hours#

Suppose members should be able to post every day between 09:00 and 18:00. Select all days and set the restriction window to 18:00–09:00. Entering 09:00–18:00 would close posting during the very hours you intended to allow it.

The selected weekday is the day the restriction begins. A Friday 18:00–09:00 window continues into Saturday morning. The Weekdays selection therefore creates five windows starting Monday through Friday. It does not mean “the group is open only on weekdays.”

That distinction matters if the intended policy is Monday–Friday, 09:00–18:00, with weekends entirely closed. Selecting Weekdays and 18:00–09:00 will not produce that schedule.

This is a worked schedule example, not a live test report. Adding Saturday and Sunday closes those nights but still leaves weekend daytime hours open. Equal start and end times do not mean “all day”: the form rejects them.

If your required policy does not fit the available window, simplify it or arrange specific manual changes with an accountable administrator. Do not announce those manual steps as an already automated schedule.

Agree on the group's clock#

A local community usually wants local hours. A distributed team may find fixed UTC easier. Either way, publish both the times and their time reference. “Our time” becomes ambiguous as soon as someone from another region joins.

Defendy's Group timezone is under General settings. The current selector offers whole-hour offsets from UTC−12 to UTC+12. These are fixed offsets, not daylight-saving calendars. A city in the option label does not guarantee that city's local time throughout the year.

The selector does not directly represent half-hour or quarter-hour zones. If using a supported offset as a reference, convert the window boundaries and check the starting day explicitly. Do not hide rounding behind a familiar city label. An agreed fixed UTC schedule is clearer than a local-time promise the saved configuration does not match.

Where seasonal clock changes matter, assign someone to review the setting, update the pinned notice and observe the next transition. A reminder in the team's calendar is an administrative practice, not a built-in night-mode exception feature.

Publish a notice members can act on#

A useful notice covers posting hours, staffed hours, the time reference and any genuine alternative contact. Here is a sample for an imaginary group with a daily overnight pause:

“Posting is open daily from 08:00 to 22:00, UTC+0. You can still read the conversation outside those hours. Our team responds on weekdays from 09:00 to 18:00, UTC+0. If a question cannot wait until posting reopens, use the contact in the group description; its staffed hours are listed there.”

Replace the sample hours and contact arrangements with verified ones before publishing it. If there is no urgent contact, explain that members need to wait for reopening. Calling a route “urgent” does not make someone available to answer it.

Post the notice before the first closure and include it in the group rules. Keep the notice and the saved settings in sync. Contradictory versions make an otherwise predictable schedule feel unreliable.

Translate the plan into Defendy settings#

1. Open Settings in @defendy_bot and select the correct group.
2. Verify its saved UTC offset under General settings.
3. Open Night mode and compare the interval with the hours when posting should be blocked.
4. Select the starting days. Walk through Friday, Saturday, Sunday and Monday before accepting the plan.
5. Toggles and valid window changes save as they are changed. Reopen the form to confirm the values, especially after a save error.
6. In a test group, observe both closure and restoration with an ordinary member account. Have an administrator supervise the first production cycle too.

Enabling the module while the saved window is active can begin applying restrictions immediately. A busy production group is therefore a poor place to explore unfamiliar controls. The night-mode setup guide explains preparation, bot permissions and recovery in more detail.

Handle holidays and one-off events deliberately#

The current form does not provide a holiday calendar, a one-time extension, or a separate window for a particular employee. An exception needs a coordinated manual change.

Record the normal setting first, then assign a person and a time to restore it. If you use /nightmode off for an evening event, the command persists the disabled state and requests permission restoration. The schedule will not return automatically the next day. Check that ordinary members can actually post: acknowledgement of a restoration request is not confirmation that it finished.

Before enabling the usual schedule again, check the time. Turning it on inside its active window can restrict the group while the event is still under way. Someone should own that decision rather than relying on an assumption about when the discussion will end.

Know when the schedule is ready#

A member should be able to answer, “What happens if I try to post on Saturday evening?” An administrator should be able to verify that answer in Telegram. The team should also have a record of the original permissions, someone responsible for exceptions and a plan for a delayed reopening.

Observe the opening as carefully as the closure. Compare permissions with the baseline, test ordinary posting and preserve restrictions that existed before the window. If a transition fails, establish the actual state before coordinating a manual correction: a pending automated restoration may still change permissions later.

Reviewed on 5 October 2026 against Defendy's current interface and implementation. This is a configuration and verification guide, not evidence that your group has passed a live test. See the night-mode reference for the current fields.