Self-check · Not a scan
A guided health check when the bot is down
Answer a few questions about a bot that is silent, slow, failing payments, or stuck because the previous developer is gone. You get a plain-language reading: likely causes, what you can check, the risk, and when a takeover plus monthly hosting is worth it.
Five questions
What this page is not
The checklist is a script in the browser. It matches the symptoms you select to causes that show up in ordinary Telegram Bot API failures and in ordinary hosting. It does not call getMe, getWebhookInfo, or any WhatsApp endpoint, and it does not measure your server. A real reading of a live bot needs the token and the host, which is exactly what this page refuses to take.
If a log line contains a token, do not paste that line into a chat, a ticket, or a form. Tokens are often printed by accident when a process starts. Anyone who can see the bot in BotFather can revoke a token that has leaked and put the new value only on the server.
Webhook and long polling
A Telegram bot does not run on Telegram’s servers. Some program of yours either waits on getUpdates (long polling) or receives HTTP POSTs at the address registered with setWebhook. The Bot API treats those as alternatives: while a webhook is set, getUpdates does not deliver the queued updates. A bot that still opens in the app can be silent because that program has exited.
getWebhookInfo reports the current URL, how many updates are waiting (pending_update_count), and the last delivery error (last_error_date, last_error_message). A rising pending count means Telegram still has the updates and your URL did not accept them. Users experience that as silence. This page cannot call getWebhookInfo for you; someone who already holds the token can, without sending the token here.
Two copies of the same token return 409 Conflict. One copy is often a laptop left polling overnight while the server also polls, or an old host whose webhook was never removed while the new host polls. Intermittent replies are what that looks like from the chat.
Expired TLS
Webhook delivery needs HTTPS on port 443, 80, 88, or 8443, and a certificate Telegram can verify. An expired certificate, or a name on the certificate that does not match the host, fails during TLS, before your route handler runs. The hosting panel can say the machine is on the whole time. If you already know that public address, a browser shows the certificate warning without any secret. If you do not know the address, do not guess it.
Certificates that renew themselves stop renewing when the renewal job dies, when port 80 is closed, or when the domain no longer points at the machine. The bot’s code did not change. The lock on the front door did.
A revoked token
Revoking the token in BotFather makes api.telegram.org answer 401 Unauthorized to the old token. The process keeps using whatever value is in its environment. Restarting without replacing that value fails the same way. The new token belongs in the server environment, with permissions that are not world-readable, and nowhere else. It does not belong in this page.
If you cannot open the bot in BotFather, you cannot revoke the token or move the webhook. The username can keep working for people who already have the chat, while control of the identity sits with whoever still has BotFather. A replacement bot is a new username and a new conversation. Existing chats do not move. The same split applies when the previous developer holds the server login: the machine can be switched off or the password changed, and the chat window will not show that.
Rate limits and the payment window
Sending too fast returns 429 Too Many Requests and retry_after, a number of seconds. Telegram’s published guidance is to stay near one message per second inside a single chat, and no more than about 20 messages per minute to the same group. A broadcast loop that ignores 429 looks like a stuck bot. It is not a dead server.
Payments are stricter than ordinary messages. The bot must answer pre_checkout_query within 10 seconds, and it must not deliver the goods until successful_payment arrives. A process wedged on a database lock misses that window. The customer sees a failed payment, or pays and receives nothing. The identifier used later for a Stars refund is stored by the bot. This site never sees it, and it does not collect or pay out funds. The Telegram page describes Stars for digital goods in that narrower sense.
The process on the server
The usual stops are ordinary. The process exited and nothing started it again. The kernel killed it for memory. The disk filled. SQLite reported database is locked because two processes opened one file. A panel that says “running” refers to the virtual machine, not to your program. If the server cannot open HTTPS to api.telegram.org, polling fails while the process stays up. A webhook fails in the other direction: Telegram cannot connect in.
A supervisor that restarts the process on exit will not fix a bad token or a bad config. The log is what distinguishes a crash from a restart loop. Do not forward a log line that contains a token.
WhatsApp is the same shape, a different door
A bot on Meta’s official WhatsApp Cloud API only sees messages Meta delivers to the webhook configured for that business app. If the URL is down or does not answer, new chats never reach the program. The app and the token live in a Meta business account. A short-lived token stops when it expires. If the previous developer is the only person who can open the app, the token cannot be rotated until that access is yours.
This page does not restate Meta’s review times, template rules, or per-country prices. Those belong to Meta and, where this site describes them, they are on the WhatsApp page, with the bill going to the account owner. Do not paste a system-user token into a form.
When to stop checking and hand it over
Keep checking if you can still open the server and the code and the fault started today. Look at the process, the certificate, and whether a second copy is running.
Hand it over when a customer may already have paid, when you cannot open both the server and the code, or when the only person who could is not answering. A takeover starts by listing which accounts still exist, then repairing or rebuilding the path that matters. Monthly hosting is the later, separate agreement: someone notices a dead process, keeps backups, and follows platform API changes. Takeover and repair start with a free check, then a quote for the problem. The hosting page is a monthly fee, priced by complexity, confirmed once the scope is clear. The takeover page is where that assessment is described. This checklist is not a quote and it is not a scan.
Take the reading to the form.
Say which platform the bot is on, what it does now, and what you can still open. A rough picture is enough to start an assessment.