How Detection Works

The probes that watch your bots, channels and account, the failures that trigger an instant check, what opens an incident, and how you are alerted.

You should never learn about a Telegram ban from a member. The program watches three things on your behalf and tells you the moment one of them stops answering — usually before the first complaint arrives.

What is watched, and how often

What	How Telegram is asked	How often
Every project bot	`getMe` with the bot's token.	Hourly; every 15 minutes on Growth. Standby bots on Growth are probed in the same pass.
Every channel and group	Our platform bot asks whether it is still an administrator with the rights it needs.	Hourly for every resource, every 15 minutes on Growth; every five minutes for a resource whose pass window is open or opens within the hour. Standby chats are probed too.
Your Telegram account	Our platform bot asks Telegram about the account you sign in with.	Every six hours.
Every member's access	Your bot asks whether each member with live access is still inside the place, and whether anyone whose access ended is still there.	Members whose access ended in the last day: every 15 minutes. Members with live access: once a day each, spread across the day; every 15 minutes on Growth. After a connector outage ends, everyone at once.

Only a transition counts. A probe that finds the same state as the last one changes nothing and sends nothing, so an incident is announced once, not once an hour. A probe that cannot reach Telegram at all keeps the previous state rather than guessing.

Instant detection

Probes catch the quiet failures. Real failures are caught the moment they happen:

A member buys access and the invite link cannot be minted, because the channel is gone or the bot lost its rights. The sale still goes through; the resource is probed immediately.
A member taps their link and the join request cannot be approved. Same: immediate probe.
We try to message you about a sale, a pass window or a support thread and Telegram answers that your account is deactivated. Your account is marked unreachable at once.

Why the account check is narrow

Telegram answers chat not found both for a banned account and for an account that simply never started our bot. Only the explicit user is deactivated answer opens an account incident, so a creator who has not talked to the bot yet is never told their account is gone.

What opens an incident

An incident is the program's word for "something is still broken and here is the way to fix it". One is opened when:

Detected	Incident kind	Also
A project bot's token is refused or the bot was deleted.	Project Bot	`connector.status_changed` webhook; a connector outage opens; on Growth with automatic failover on and a healthy standby bot, the standby takes over.
A channel or group no longer exists, or our bot was removed from it.	Channels and Groups	`project.resource.status_changed` webhook; on Growth with automatic failover on, the swap runs.
Our bot is still in the chat but lost its administrator role or its rights.	Channels and Groups	The incident names the missing right; giving it back resolves the incident without a swap.
Telegram reports the account you sign in with as deactivated.	Telegram Account	The alert goes to your backup Telegram account when you registered one.

An incident resolves itself when a later probe finds the thing healthy again — you gave the bot its rights back, Telegram lifted a restriction — or when a recovery replaces it.

How you are told

Every incident reaches you three ways:

Email, with a one-tap button into the recovery page that pre-selects the incident.
Telegram, a direct message from our platform bot in your language, with a signed link that signs you in and lands on the page. For an account incident the message goes to your backup Telegram account, since the main one can no longer receive it.
The dashboard, where a banner above every page reads "Start Recovery" until the incident is resolved.

Your members are told too, in their own words: see What your members see.

What is not detected

A content restriction on a channel that still answers. Telegram can restrict a channel for a content flag while the Bot API keeps working. Nothing stops, so nothing is detected; if you want to move anyway, the recovery page lets you run a channel recovery without a detected incident, and the all-clear notice tells you it spends the allowance like any other.
A restriction on your account that still lets it be reached. Same reasoning: if Telegram still answers for the account, we cannot tell.
Anything about content. Once a channel is banned, no API can read its history. This is why the live mirror on Growth copies posts before anything happens; see Active Disaster Prevention.

Example: a bot token revoked by mistake

A creator regenerates their bot token in BotFather while tidying up, forgetting that Subscriby holds the old one.

10:00 — the hourly bot probe gets Unauthorized from Telegram. The bot is marked degraded with the reason Bot token refused, a Project Bot incident opens, the creator gets an email and a Telegram message, and any project.bot.status_changed webhook fires with status: degraded, reason: telegram_api_unauthorized.
10:02 — members who message the bot get nothing back from Telegram, but members who open the portal see Access Is Being Restored.
10:15 — the creator opens the page from the alert, pastes the new token into Replace the Bot, and the same bot row is rebound: every member chat follows, the webhook and commands are registered, and the incident resolves. Because nothing about the bot's identity changed, members do not even need to press Start again.

Had they regenerated the token on purpose and pasted it into the project's bot settings instead, the ordinary bot-connection flow would have re-registered the webhook and the next probe would have resolved the incident on its own.

What a refusal starts

A probe that comes back with the platform refusing the installation outright — Bot token refused or Bot not found — does more than open the incident above: it opens a connector outage. From that moment every plan that unlocks a place on that connector is off sale, the Connectors page badges the installation Sales Paused, and connector.outage_opened fires. The outage ends when the probe finds the installation healthy again, when you relink a bot, when a standby takes over, or when you uninstall the connector; members whose paid access overlapped an outage of an hour or more then have the lost time banked on their purchase through Outage Compensation. A rate limit or a passing API error still marks the installation degraded, but opens no outage. The quarter-hour cadence on Growth is what bounds an outage's undetected stretch, and so what the compensation is measured from, to fifteen minutes.