The chatbot went silent: debugging failures that produce no error

A running process does not prove a chatbot can receive a message, finish the requested work and send a reply. When a Telegram bot goes silent, trace one harmless test message across those boundaries before restarting services or changing delivery settings.

The checks below are diagnostic hypotheses, not measured failure frequencies. WhatsApp and website widgets have different delivery and permission models; do not apply Telegram API instructions to them.

Start with one message and an evidence record

Record the test time, expected reply and a correlation identifier. Ask the operator to locate the incoming update, handler result, dependency response and outbound Telegram response. Keep tokens and message contents out of shared logs; use a harmless fixture rather than customer data.

Test time / correlation ID:
Incoming update observed: YES / NO / UNKNOWN
Handler completed: YES / NO / UNKNOWN
Dependency result / error:
Outbound API response / message ID:
User-visible reply confirmed: YES / NO / UNKNOWN
Pending work / recovery owner:

An API acceptance response and a visible reply are separate observations. A missing log entry is also not proof that an update never arrived: first establish what that log actually records.

Process up, messenger unreachable

A worker can remain alive while an outbound connection waits or an inbound webhook cannot reach its endpoint. Check DNS resolution, connection and TLS errors, webhook responses and dependency timeouts separately. A successful request to an unrelated website does not establish reachability of the bot API.

A Mini App loading on a phone exercises another path: the device can reach the web application while the bot worker cannot finish an API call. Test the failing path itself.

Ask the operator for dated evidence before changing routing or delivery mode. IP pinning and switching from webhooks to polling are configuration changes, not default diagnostic steps. A supervisor can restart an exited process, but repeated restarts do not repair a network route or reconcile work already accepted.

Check the configured receiver without dropping work

Telegram documents two update-delivery methods: webhooks and getUpdates. They cannot be used together while an outgoing webhook is set. Ask the authorised operator to inspect getWebhookInfo through the existing secure administration tool. Its URL, pending update count and recent error fields help compare the configured receiver with the intended deployment.

Do not paste a token-bearing API URL into a browser or shared diagnostic report. Check the deployed instances and their delivery configuration; an unexpected receiver or duplicate polling process is a hypothesis to investigate, not proof of every missing reply.

Preserve pending updates during diagnosis. Telegram’s deleteWebhook method has an option named drop_pending_updates that discards queued updates when enabled. It is not a routine recovery step. Changing delivery mode requires a reviewed handover that preserves queued work and reconciles already processed updates. This article does not instruct you to perform that change.

Six symptoms to investigate

Check marks appear, but no reply arrives

Telegram’s chat indicators do not prove your handler received an update, returned HTTP200 or completed a CRM request. Inspect the receipt and processing evidence. Possible failures include an unhandled exception, a dependency timeout or a terminated worker; the indicator alone cannot choose between them.

A fallback should state the known outcome accurately. Do not say a request is processing unless it was accepted into a recoverable workflow. Record a safe error identifier and provide a retry or support path that avoids duplicate actions.

An inline button keeps showing a loading indicator

Telegram requires answerCallbackQuery to acknowledge a callback query, even if no notification is needed. Acknowledge promptly and handle longer work separately where appropriate. That acknowledgement clears client waiting; it does not prove the requested business action succeeded. Do not diagnose a missing acknowledgement from an exact number of elapsed seconds alone.

The welcome message works, but later replies do not

Inspect the state transition, validation branch and receiving instance for the next update. A validator may reject input without giving a useful prompt, or a deployment may route work inconsistently. Return a clear validation response and verify that the relevant session state is available to the intended worker. These are candidates, not an exhaustive list of causes.

A website form succeeds, but its notification is missing

First check whether the lead was durably accepted. Then inspect notification dispatch and the destination response. The form confirmation should describe the accepted state, not imply every downstream channel has completed.

Use a durable outbox or another recoverable dispatch mechanism appropriate to the application. Record attempts and their outcomes. Before retrying an ambiguous timeout, reconcile the previous effect or use duplicate protection. A local file alone does not establish safe concurrent writes, retention or recovery.

The start command gets no answer

Check service startup and restart history, configured delivery mode, authentication errors and whether the incoming update reached a handler. A missing welcome message has no single established failure rate here. Preserve queue state while collecting evidence; do not clear it to make the counters look healthy.

Replies arrive after a repeated delay

Measure receipt-to-handler, dependency and outbound timings independently. Blocking work in an asynchronous handler, dependency timeouts and rate limiting can each add delay. When Telegram returns a flood-control response with retry_after, respect that value rather than immediately retrying. A repeated delay alone does not identify a Telegram timeout or prove the server is healthy.

Check permissions at the failing action

For channel posts, inspect the bot’s current administrator status and relevant rights, including can_post_messages where applicable. Yesterday’s successful post is not evidence of today’s permission. Keep this separate from transport failures and from a chat handler that never ran.

Monitor a completed path

Choose a harmless test that exercises the path users depend on, and define its expected response and observation window. A process check remains useful, but it should not be the only signal. Use an independent alert path where practical and record whether the test reached receipt, processing or reply confirmation.

Start with a written brief if failures recur: the affected path, dated evidence, outstanding work and recovery decision are a more useful starting point than another restart.

Sources

Telegram documentation checked15October2026:

• Getting updates, getWebhookInfo and deleteWebhook.
• Callback acknowledgement.
• Response parameters and retry_after.
• Telegram check marks.