---
title: "Read-only account health check"
locale: en
url: https://tlg.builera.app/en/docs/agent-playbooks/check-accounts
verified: 2026-10-24
app_version: "2.0"
---

# Read-only account health check

Gather account status within the connection's scope and report issues that need a person without changing configuration.


## 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`](https://tlg.builera.app/en/docs/reference/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`](https://tlg.builera.app/en/docs/reference/rest/accounts.get).
4. If permitted, read [`stats.health`](https://tlg.builera.app/en/docs/reference/rest/stats.health) with `tools_run`.
5. If investigation is needed, read [`alerts.list`](https://tlg.builera.app/en/docs/reference/rest/alerts.list) with `tools_run`.
6. Read [`audit.list`](https://tlg.builera.app/en/docs/reference/rest/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.

> [!IMPORTANT]
> Stop point — ask the person
>
> If you find that an account needs another sign-in, a different proxy, a different machine or re-enabling, stop at the report. Ask for a separate decision before moving to write operations.

## 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](https://tlg.builera.app/en/docs/concepts/safety-states) and [account management](https://tlg.builera.app/en/docs/guides/accounts-manage).