How does the auto-delete timer work in Telegram chats and groups?
The auto-delete timer in Telegram chats and groups is a per-conversation rule that tells Telegram's servers to erase messages on a fixed schedule for every participant, with no one pressing a delete button. It is not a filter, a local cache cleaner, or something applied message by message. Once enabled, it becomes a standing policy for that conversation and keeps running long after the person who configured it has stopped thinking about it. That persistence is why the feature deserves more attention than the single tap it takes to switch on. This guide covers the mechanics, the shortest setup paths on Android, iOS, and Desktop, the situations where the timer quietly fails to help, and the reproducible checks you can run on your own client before committing a large group to a retention rule.
What the Auto-Delete Timer Actually Does
Cloud chats in Telegram live on the company's servers. Every device you sign in on is a view onto that shared store, not a separate mailbox. In engineering terms, the auto-delete timer is a time-to-live value — a TTL, meaning the lifespan a record is allowed before the system discards it — attached to the conversation itself. Set it to one week, and each message sent afterward carries an expiry of one week from the moment it leaves your device. When that expiry passes, the server drops the message and pushes the removal outward to every connected client, including devices that were offline when the deletion occurred. Nothing has to be running on your phone for this to happen, which is the single most important thing to internalise about the feature.
Because deletion happens at the source rather than at the edge, the effects are symmetrical: you lose the message too, not just your recipients. Operators accustomed to inbox rules in email, where messages are moved out of sight on one account, frequently misread the Telegram setting on first contact. A useful mental model is a shredder installed in the wall of the room, running on a timer, rather than a filing cabinet that only you can open. The rest of this article builds on that model, because most practical advice — what to set, when not to set it, how to test it — follows from the fact that the shredder is shared.
Three mechanisms that get confused with each other
Telegram ships more than one way to make messages vanish, and the labels sit close enough together in the interface that mixing them up is the most common support question on the topic. The clearest way to separate them is by the unit of deletion: does the rule apply to a whole conversation, to one message, or to a manual selection you make on the spot?
| Mechanism | Where it applies | Unit of deletion | Clock anchor |
|---|---|---|---|
| Auto-Delete Messages | Cloud chats, groups, channels, Saved Messages | The entire conversation | When the message is sent |
| Self-Destruct Timer | Secret Chats only | Each message individually | Tied to the recipient viewing it |
| Delete for everyone / Clear history | Anywhere, subject to permissions | Whatever you select | The moment you act |
The first row is the subject of this article and the one with the widest blast radius, because it applies to everyone in the conversation whether or not they chose it. The second row is the older, narrower feature: a Secret Chat self-destruct timer is set per message stream and, in Telegram's design, the countdown is anchored to viewing rather than sending, so an unread message does not decay in the same way. That distinction is worth confirming on a two-device test if it matters to your workflow. The third row is not automatic at all; it is an action, and it depends on whether you have the right to delete other people's messages.
Why Operators Reach for It: Three Real Pain Points
A community group with a few thousand members and a rotating volunteer moderation team is the classic case. Invite links get posted, phone numbers get shared during a dispute, and a year later the search box still surfaces a stranger's contact details from a thread nobody remembers. Setting the group to a one-month auto-delete does not fix the link that is already circulating, but it caps the accumulation: everything from this month forward has an end date. The trade-off is immediate — new members joining in month three see far less backlog, and moderators lose the ability to review how a long-running dispute started.
The second pattern is a small operations team that uses a private group as a scratchpad for incidents. Screenshots of dashboards, temporary credentials pasted in haste, half-finished runbooks — all of it is genuinely sensitive for about seventy-two hours and genuinely worthless after that. Here the timer is close to free, provided the team keeps durable knowledge somewhere else. The failure mode appears when the scratchpad quietly becomes the only copy of an incident postmortem, and the timer erases the organisation's memory on schedule.
The third is a support conversation in a one-to-one chat where a customer pastes a delivery address or an order number. Either party can set a short timer, and the announcement that appears in the chat makes the intent visible rather than secret. That visibility matters for trust: a timer set silently would look like a trap, whereas the visible service line converts it into a stated policy. If you are rolling this out to a support team, the visible announcement is a feature to lean on, not an annoyance to work around.
How the Countdown Is Anchored
The timer runs from the moment of sending, measured against Telegram's server clock. It does not start when the recipient opens the chat, pause while a device is offline, or get influenced by the local time on anybody's phone. A message sent at 23:50 with a one-day timer expires the following evening whether or not it was ever read. This is a meaningful difference from the Secret Chat model and the reason auto-delete is unsuitable for anything where the recipient's attention is part of the condition.
Two further consequences follow from server-side anchoring. First, the countdown continues during outages of your own device; you cannot freeze it by going offline. Second, the removal propagates as a normal sync event, so a device that comes back online after a week receives the deletions along with everything else. In practice, there is no moment when different participants hold materially different views of the chat — the divergence window is measured in seconds to minutes, not days.
What happens to messages that already exist
This is the question that causes the most damage when answered wrongly, and it is also one where behaviour has shifted across client versions, so treat what follows as a working hypothesis plus a test rather than a guarantee. Empirical observation suggests that when a timer is applied to a chat with existing history, messages already older than the new period are not exempt — they are removed in a sweep shortly after the setting takes effect. The confirmation sheet shown in current clients alludes to this, which is why the sheet is worth reading rather than dismissing.
Before you set a short timer on a long-lived chat: export or copy anything you need first. A one-day timer applied to a two-year-old group is functionally a mass deletion, and there is no undo button. The verification protocol later in this article lets you observe the sweep on a throwaway chat before you try it anywhere that matters.
Setting the Timer in a Private Chat
The entry point is always inside the conversation's own information panel rather than in the message context menu, which is useful to remember when a new release moves things around. In a one-to-one cloud chat, either participant can change the timer, and both are notified when it happens. The paths below describe the shortest route on each platform as of the latest version at the time of writing; exact label wording varies by language pack, so anchor on the concept rather than a literal string.
Android
Open the chat, tap the contact's name in the header to open their profile, then open the overflow menu (three dots) on that screen and choose the auto-delete entry. The picker offers preset periods plus a custom option. Confirm, and a service line appears in the chat stating the new period. A secondary route exists from the chat list if you long-press a conversation and open its info from there, but the header route is fewer taps and less error-prone.
iOS
On iOS the option generally appears as a row on the profile screen you reach by tapping the chat title, rather than behind an overflow menu — the platform convention is to expose settings as list rows. Tap it, choose a period, confirm. If you cannot find the row, check that you are in a cloud chat and not a Secret Chat: Secret Chats expose the self-destruct timer instead, and the two look similar enough that people often report the wrong one as missing.
Desktop and Web
On the desktop client, click the chat name in the header to open the right-hand information panel; the auto-delete control sits among the conversation settings there. The overflow menu next to the search field is an alternative entry on most builds. Web clients follow the desktop layout closely, though label placement has moved between Web releases — if the panel does not show it, open the chat's full info view rather than hunting through global settings. Global settings are the wrong place to look for a per-chat timer, and that misunderstanding accounts for a fair share of 'the feature disappeared' reports.
Tip: if a client version also exposes a default timer for new conversations under Privacy and Security, treat that as a convenience layer on top of the per-chat setting, not a replacement. Verify what your build actually offers before assuming a global default exists — the presence of that entry has varied across releases and platforms.
When the entry is missing or greyed out
Four causes cover almost every report. You are in a Secret Chat, where the correct control is the self-destruct timer. You are in a group or channel without the administrative rights that the setting requires. You are on an older client that predates the group-level rollout, in which case updating is the fix. Or you are looking at the chat's notification settings, which sit in a visually similar panel but govern something entirely different. Work through them in that order; the fourth is more common than people expect because both screens are reached from the same header tap.
Setting the Timer in Groups and Channels
In groups the control moves from the conversation's own settings to the group's administration surface, and the permission model becomes the deciding factor. As a rule of thumb, treat the ability to change the auto-delete period as part of the same privilege bundle that lets someone edit the group's name, photo, and description. If you can rename the group, you can probably change the timer; if the row is read-only for you, that is the system telling you something about your role rather than a bug.
What non-admins see is important for expectation management. Regular members observe the current period in the group's info screen and see the service line when it changes, but they cannot alter it. That visibility makes the feature defensible in a community setting: nobody can claim afterward that their messages were deleted by a hidden rule. When you roll out a retention policy to a large group, pin a short explanation alongside the change so the service line has context, because the line itself is terse.
Channels behave similarly but with a sharper asymmetry: the audience has no participation to protect, so the timer is purely an editorial decision about how far back the public archive should reach. A channel used for time-sensitive announcements can reasonably delete after a week; a channel that functions as a reference library should not use the timer at all, because the archive is the product. In both cases the setting lives with the channel's administrative controls rather than with the reader's preferences.
Choosing a Period: A Decision Framework
The presets exist for a reason — most conversations fall into one of three rhythms — but the custom option is where the feature earns its keep, because the right answer is often 'three days' or 'two weeks' rather than a round number. Two questions narrow the choice faster than any table: how long does this content stay useful, and how bad is it if it is still searchable in two years? The first sets the floor, the second sets the ceiling, and the period you pick should sit between them.
| Conversation type | Typical period | Reasoning |
|---|---|---|
| Event logistics group | One day | Everything is stale once the event ends |
| Internal ops scratchpad | One week | Covers an incident cycle without hoarding credentials |
| Community Q&A group | One month | Long enough for newcomers to catch up, short enough to age out contacts |
| Knowledge base or reference channel | Do not enable | The archive is the value; deletion destroys it |
The fourth row deserves emphasis because it is where most organisations get hurt. A group that has quietly become the authoritative record of decisions — who approved what, when a vendor was switched, why a policy changed — cannot tolerate a timer, no matter how tidy the shorter history looks. The correct fix in that case is structural: move durable content into a channel or a pinned index where it is deliberately curated, and keep the timer on the chatty group. Splitting the conversation by purpose is cheaper than trying to guess a period that satisfies both.
Side Effects Worth Planning Around
Search is the most visible casualty. Once the server drops a message, it stops appearing in results for everyone, which is usually the intent — but teams often discover after the fact that their de facto documentation search was doing more work than they credited it with. A reproducible check: before enabling a timer, search the chat for the three terms your team asks about most often, note how many hits come from messages older than the intended period, and decide whether losing those hits is acceptable. That five-minute audit predicts the complaints you will field a month later.
Pinned messages need explicit thought. The timer governs messages, not pins as a category, so a pinned message that ages past the period is a candidate for removal like any other. Empirical observation suggests pinned items do disappear once their own expiry passes, but the interaction has been inconsistent enough across versions that you should confirm it in your own client rather than rely on a blog post — pin an old test message, set a short period, and watch whether the pin survives the sweep. If pinned durability matters, the practical answer is to keep the pinned content in a place the timer does not touch.
Exports are the third area. Telegram Desktop can export a chat's history, but only what still exists; running the export after the timer has swept is not a recovery method. The correct order is export first, then enable. The same logic applies to moderation evidence: if your process depends on reviewing a reported message days later, a one-day timer can delete the evidence before the report is handled. Where that risk is real, route reports into a separate destination that is exempt from the timer rather than weakening the retention rule across the whole group.
There is also a softer effect on how conversations feel. Groups with short timers tend to produce less long-form discussion, because regulars learn that lengthy answers evaporate and stop writing them. That is not a defect, but it is a cultural change, and it usually arrives without anyone announcing it. If your community's value comes from accumulated threads rather than real-time chatter, the timer is working against you regardless of how carefully you pick the period.
Forwards, Replies, and Screenshots
A forwarded copy does not inherit the original's timer. The moment a message leaves the source chat it becomes an ordinary message in the destination, subject to that chat's rules — which may be no rule at all. This surprises people who assume the expiry travels with the content, and it is the strongest argument for treating auto-delete as a hygiene measure rather than a confidentiality control. A recipient with forwarding rights can lift a message out of a one-day chat and keep it indefinitely in Saved Messages.
Screenshots are likewise unaffected in cloud chats. The timer deletes the server copy; it does nothing about what another person's device captured while the message existed. If the requirement is genuinely 'this must not persist anywhere', the honest answer is that no messaging client can promise that, and the closest available primitive is a Secret Chat with a self-destruct timer, which at least removes forwarding as an option. Framing the timer accurately when you introduce it — hygiene, not secrecy — prevents a painful misunderstanding later.
Bots, API Access, and the Limits of Automation
The obvious operational wish is to manage retention programmatically. Here the guidance has to be conservative, because the surface differs sharply between the Bot API and the client API. As of this writing, the Bot API reference does not document a general method for a bot to set a chat's auto-delete period; bots primarily delete specific messages they are permitted to remove. If you are building against the Bot API, check the current reference for your version before designing around a capability you may not have — and note that service messages announcing timer changes may or may not be surfaced to your handler depending on version.
The Telegram client API, the MTProto layer that official and third-party clients use, does expose a method for setting a peer's history TTL, taking a peer and a period as parameters and returning the updated state. That is the hook custom tooling builds on, and it is the reason a well-maintained third-party client can set the timer even when a bot cannot. It also means the capability is gated by whatever rights the authenticated account holds, so an automation account still needs the same administrative position a human would.
Least privilege, applied here: do not grant a helper bot full administrator rights merely to run cleanup logic. Grant the delete-messages permission it needs and nothing else. An automation account with change-info rights can rewrite your group's retention policy, and the timer it sets will delete history for everyone — a privilege escalation with a very quiet failure mode.
Troubleshooting: Symptom to Resolution
Most failures fall into a small number of buckets, and the fastest route is to identify which bucket you are in before touching settings. The table below maps the symptom to the likely cause, then to a check that produces evidence rather than a guess.
| Symptom | Likely cause | Verification |
|---|---|---|
| Messages never disappear | Timer is off, or the chat is a Secret Chat | Open the chat info panel and read the current period |
| Timer reverted to off overnight | Another participant or admin changed it | Scan the chat for the service line recording the change |
| Setting is absent from the panel | Insufficient role, or outdated client | Try the same action in a test group where you are the creator |
| Old history vanished right after enabling | Retroactive sweep of messages past the new period | Reproduce on a throwaway chat with known dates |
| One device still shows a deleted message | Local cache has not synced yet | Reopen the chat or restart the client and recheck |
The second row is worth dwelling on because it is not a bug. In a one-to-one chat both parties hold the pen, and in a group any sufficiently privileged administrator does too. A retention policy that only one person believes in will not survive contact with a colleague who finds it inconvenient, and the visible service line is the audit trail that tells you when it happened. If the policy is meant to be binding, say so in the group's description and pin a note; the setting alone is not governance.
The last row reflects ordinary eventual consistency rather than a failure. Deletion propagates quickly, but a client that has been asleep may render its cached copy until it refreshes. If a message still shows after a client restart and a manual sync, then you have something worth investigating; before that, you are probably watching normal lag.
A Reproducible Verification Protocol
Because behaviour has shifted across versions and because the retroactive sweep is the risky part, test before you deploy. The protocol below takes about fifteen minutes and produces observed facts rather than assurances from an article.
- Create a test group with two accounts you control. Post at least ten messages, including one with a link, one with an image, and one you pin. Note the timestamp of the oldest.
- Confirm the group currently has no timer by opening its info panel and reading the value aloud to yourself — this establishes the baseline.
- Set the shortest period the picker allows and read the confirmation sheet in full before accepting.
- Watch the chat immediately. If a retroactive sweep occurs, older messages disappear within a short window; note which ones, and specifically whether the pinned message survived.
- Send a new message and record its exact send time. Check again after a fifth of the period has elapsed to confirm the countdown is running from send time rather than from a read event.
- Ask the second account to change the timer to a different value and observe whether the service line appears and whether your client reflects the change.
- Take the second account offline, let a message expire, then bring it back online and confirm the deletion propagates rather than the cached copy reappearing.
Write down what you observed and the client version you observed it on. That note is worth more than any general claim, because it describes your deployment rather than someone else's, and it gives you something concrete to compare against after the next update.
Compliance and Recordkeeping Boundaries
Auto-delete is a retention control, which means it belongs in the same conversation as your organisation's retention obligations rather than in a chat about interface tweaks. If a regulation or internal policy requires you to keep records of client communications for a defined period, a timer that shreds them in seven days is a compliance defect, not a privacy win. The reverse is also true: keeping sensitive chatter indefinitely because nobody got around to configuring anything is the more common failure, and it is the one this feature was built to address.
The practical artefact is a short retention matrix — conversation type, purpose, period, and where durable content is stored instead. Once that exists, the configuration becomes mechanical and auditable: someone can open each group, read the current period, and confirm it matches the matrix. Without it, every group drifts toward whatever the last administrator felt like, and the drift is invisible until an audit or an incident surfaces it.
When to Use It, and When Not To
The admission criteria are narrow enough to state plainly. Enable the timer when the conversation is primarily real-time coordination, when the content's value decays on a predictable schedule, when the archive is curated elsewhere, and when every participant can be told the rule in one sentence. A volunteer coordination group, an incident channel, a support inbox — all fit. The presence of a documented alternative home for durable knowledge is what makes the rest safe.
Do not enable it when the chat is the record of decisions, when moderation or legal review depends on messages surviving longer than the period, when participants include people who were not present for the announcement, or when the content is public reference material. A channel that documents a product, a group that tracks approvals, a chat where disputes are adjudicated — these fail the test on the first criterion and no amount of period-tuning rescues them.
Best Practices Checklist
- Export or copy anything you cannot reconstruct before the first short timer is set on a chat with history.
- Run the verification protocol on a throwaway group before changing a production conversation.
- Announce the period in the group description so the service line has context and newcomers are not surprised.
- Keep durable content in a channel or pinned index that the timer does not govern, and link to it from the chatty group.
- Match the period to the content's decay rate rather than to a round number; custom values exist for this reason.
- Grant bots only the delete-messages permission they need, never change-info, if automation is involved.
- Re-check the configured period after every major client update, since panels get reorganised.
- Record the period in your retention matrix and audit it quarterly.
Used as a sequence, the checklist turns a vague intention into an auditable configuration: export first, test second, announce third, and keep durable content outside the timer's reach. The order matters less than doing the export and the test before a production chat is touched, because those are the two steps that are hard to reverse once the sweep has run.
Frequently Asked Questions
Does the auto-delete countdown start when the message is read?
No. In cloud chats, groups, and channels the countdown runs from the moment the message is sent, measured against Telegram's server clock. Unread messages expire on schedule. The read-anchored behaviour people remember belongs to the self-destruct timer in Secret Chats, which is a different mechanism.
Can I set a different timer for individual messages?
Not in cloud chats. The auto-delete setting applies to the whole conversation, so every message follows the same period. Per-message expiry exists only in Secret Chats through the self-destruct timer, and even there it applies as a stream setting rather than a per-bubble one.
Do other members know the timer is on?
Yes. The current period is visible in the conversation's info panel, and a change produces a service line in the chat. The setting is not covert, which is deliberate: a shared deletion rule should be visible to the people it affects.
Does a forwarded copy keep the original's expiry?
No. A forward becomes a new message in the destination chat and follows that chat's rules, which may mean no expiry at all. Treat auto-delete as hygiene rather than a confidentiality control, especially in chats where forwarding is permitted.
Can a bot enable or disable the timer for me?
As of this writing the Bot API reference does not document a general method for setting a chat's auto-delete period; bots mainly delete specific messages they are permitted to remove. The client API does expose a history-TTL method, so custom clients and tooling built on it can change the setting when the authenticated account holds the necessary rights. Check the current API reference for your version before designing around it.
Where to Go From Here
The auto-delete timer is a small switch attached to a large consequence: it converts a conversation from an accumulating archive into a rolling window. Used deliberately, it removes the slow buildup of contact details and stale credentials that makes large groups uncomfortable to search. Used carelessly, it removes the record of why decisions were made, and it does so silently and on schedule. The difference is almost never the period you pick — it is whether you decided first and configured second.
Three concrete next steps are worth taking this week. Write the one-page retention matrix for the conversations you actually run, even if it has only four rows. Run the verification protocol on a throwaway group so you know how your current client behaves rather than how an article says it behaves. Then walk your largest group and check its configured period against the matrix — you will likely find at least one conversation that has been quietly deleting history nobody intended to lose, or retaining content nobody meant to keep.