Read-only account health check

#Goal

You check the accounts the connection may view and produce an evidence-based report. This playbook is read-only: do not sign in, change proxies, enable accounts or test by sending messages.

#Permissions needed

• accounts.read to view accounts.
• stats.read if you need health or limit statistics.
• audit.read if you need to cross-check alerts and logs.

Infrastructure read permissions do not automatically include account read permissions. Only use operations the current connection is actually allowed to call.

#Ask the person before

Define the scope: which accounts to check, whether the task is a status report or investigation of a specific incident, and who receives the report.

If the person asks you to “fix it too,” separate the fix from this check. A request to check is not consent to sign in again, change machines or change proxies.

#Check first

Call whoami to confirm the workspace, connection and granted accounts. Use tools_search to find the required operations and tools_describe to read their schemas before calling them.

Returned lists only reflect what you can see. Do not conclude that the workspace has no other accounts if the connection has a restricted account scope.

#Steps

1. Call accounts_list, corresponding to REST accounts.list.
2. Follow pagination until you cover the agreed scope.
3. Call accounts_get for each account to check, corresponding to accounts.get.
4. If permitted, read stats.health with tools_run.
5. If investigation is needed, read alerts.list with tools_run.
6. Read audit.list when you need to cross-check recent changes.
7. Summarize each account: observed data, anomalies and decisions that need a person.

Do not turn a machine or connection status into a definite conclusion about a Telegram session. Report account, session, proxy and machine aspects separately when the results distinguish them.

#Check after

The report must state when you checked, what scope you covered and which parts you lacked permission to read. Distinguish “no errors were returned” from “fully checked.”

Do not include keys, login sessions or secret proxy information in the report. You may use account names in an authorized environment, but externally shared documents need fake or redacted data.

#On errors

If an account is no longer accessible, record the permission limit instead of trying another identity. If a read fails, do not infer that the account is broken.

When rate-limited, wait as directed by the response. Do not open additional connections to keep reading faster.

#When to stop

Stop when you have checked the full scope, the requester cancels, the connection loses permission or there is not enough data to reach a safe conclusion. The final result is a report, not a list of changes you made on your own.

See also safety states and account management.