project.resource.status_changed
A channel or group enters or exits a degraded state — banned, deleted, or the bot lost its rights.
Fires on a transition, not on a schedule. Subscriby probes every linked channel and group hourly, every five minutes while a pass window is open or imminent, and immediately when real work fails (an invite link cannot be minted, a join request cannot be approved). You get one event when the resource breaks and one when it recovers, never an event per probe.
When this fires
A Telegram channel or group linked to a project transitions into or out of a degraded state. The degraded reasons are:
reason | What Telegram told us | Recovery |
|---|---|---|
chat_not_found | The chat no longer exists — deleted, or banned by Telegram. | Replace the chat (a channel recovery). |
bot_removed | Our bot was removed from the chat, so it can no longer admit or remove members. | Re-add the bot as an administrator, or replace the chat. |
bot_not_administrator | The bot is still in the chat but lost its administrator role. | Promote it again with the invite and restrict rights. |
bot_missing_rights | The bot is an administrator without the invite users or restrict members right. | Grant both rights again. |
connector_api_error | The platform refused the probe for a reason we could not classify. | Re-check; replace the chat if it persists. |
The healthy event carries reason: null and fires when a probe finds the resource answering again, or when a recovery re-points it at a new chat.
A chat_not_found or bot_removed transition also opens a recovery incident on the creator's Disaster Recovery page, alerts them by email and Telegram, and — on Growth, with automatic failover switched on — swaps the resource for its standby without anyone signed in.
It does not fire when:
- A probe finds the same state as last time. Only transitions are announced.
- A probe cannot reach Telegram at all. A transport failure keeps the previous state.
- The resource is a manual perk. Only Telegram channels and groups are probed.
Required ability
project-resource:view — token must carry this at mint time to subscribe an endpoint to this event.
Payload
{
"id": "evt_01HX...",
"type": "project.resource.status_changed",
"created_at": "2026-09-07T10:05:00Z",
"api_version": "2026-05-01",
"project_id": "7f3d1c92-8b45-4e6a-9d21-5c8e0a4b6f13",
"data": {
"project_id": "7f3d1c92-8b45-4e6a-9d21-5c8e0a4b6f13",
"resource_id": "b73c5f21-9d80-4a6e-8215-4f70ce13a9d6",
"status": "degraded",
"reason": "chat_not_found"
}
}Field reference
| Field | Type | Notes |
|---|---|---|
id | string ULID | Unique event id, prefixed evt_. Use for idempotent processing. |
type | string | Always project.resource.status_changed for this event. |
created_at | ISO 8601 timestamp | Server-side emission time. |
api_version | string | Webhook API contract version. |
project_id | string UUID | Project this event belongs to. |
data.project_id | string UUID | Same project, repeated for consumers that read data alone. |
data.resource_id | string UUID | The channel or group whose health changed. |
data.status | enum: healthy, degraded | The state after the transition. |
data.reason | enum: chat_not_found, bot_removed, bot_not_administrator, bot_missing_rights, connector_api_error, nullable | Why it is degraded. null on a healthy transition. |
Related events
connector.status_changed— the same idea for the project's installation.project.resource.updated— fires withchanges.space_idwhen a recovery re-points the resource at a replacement place.
How is this guide?