How Detection Works
The probes that watch your bots, places and connected account, the failures that trigger an instant check, what opens an incident, and how you are alerted.
You should never learn about a platform 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 the platform is asked | How often |
|---|---|---|
| Every project bot | The connector asks the platform whether the bot's credentials are still accepted. | 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 connected account | Our platform bot asks the platform 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 the platform 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 their access cannot be issued, because the place is gone or the bot lost its rights. The sale still goes through; the resource is probed immediately.
- A member uses their access and the connector cannot admit them. Same: immediate probe.
- We try to message you about a sale, a pass window or a support thread and the platform answers that your account is deactivated. Your account is marked unreachable at once.
Why the account check is narrow
A platform usually answers the same way for a banned account and for an account that simply never started our bot. Only an explicit "this account 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 credentials are refused or the bot was deleted. | Connection | connector.status_changed webhook; a connector outage opens; on Growth with automatic failover on and a healthy standby bot, the standby takes over. |
| A place no longer exists, or our bot was removed from it. | Places | project.resource.status_changed webhook; on Growth with automatic failover on, the swap runs. |
| Our bot is still in the place but lost its administrator role or its rights. | Places | The incident names the missing right; giving it back resolves the incident without a swap. |
| The platform reports the account you sign in with as deactivated. | Connected Account | The alert goes to your backup account when you registered one. |
The recovery page names each kind in your connector's own words. An incident resolves itself when a later probe finds the thing healthy again — you gave the bot its rights back, the platform 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.
- Your connected account, 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 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 place that still answers. A platform can restrict a place for a content flag while its bot API keeps working. Nothing stops, so nothing is detected; if you want to move anyway, the recovery page lets you run a place 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 the platform 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's token on the platform while tidying up, forgetting that Subscriby holds the old one.
- 10:00 — the hourly bot probe is refused by the platform. The bot is marked degraded with the reason Bot token refused, a Connection incident opens, the creator gets an email and a message on their connected account, and any
connector.status_changedwebhook fires withstatus: degraded, reason: connector_api_unauthorized. - 10:02 — members who message the bot get nothing back from the platform, 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.
How is this guide?
Disaster Recovery Program
What happens when a platform bans or restricts the account you sign in with, the bot that serves a project or a place your plans grant — how Subscriby detects it, how you recover in minutes with every paying member re-admitted automatically, and the fair-use rules that keep the program honest.
Connector Outages
What happens to sales, access and paying members when a platform refuses your project's bot or app, and how Subscriby compensates members when it answers again.