Telebot surfaces errors from handlers, the Telegram API, and the bot internals through a unified pipeline. This page explains each layer and how to configure them.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/tucnak/telebot/llms.txt
Use this file to discover all available pages before exploring further.
How Handler Errors Flow
When a handler returns a non-nil error, Telebot passes it to theOnError callback that was configured in Settings. If OnError is not set, the default implementation logs the error with the update ID:
Configuring a Global Error Handler
Settings.OnError is a function with the signature func(error, Context). The Context parameter may be nil when the error originates outside a handler (for example, during polling).
Telebot Error Variables
Thetelebot package defines sentinel errors for common bot-level failure cases:
| Error | When it occurs |
|---|---|
ErrBadRecipient | b.Send was called with a nil recipient |
ErrUnsupportedWhat | The what argument passed to Send/Reply is not a string or Sendable |
ErrCouldNotUpdate | The long poller could not fetch updates from Telegram |
ErrTrueResult | Telegram responded with {"ok":true,"result":true} instead of an object |
ErrBadContext | A context method that requires a message was called on a non-message update |
Telegram API Error Types
Errors returned from the Telegram API are represented as*tele.Error:
Error() method formats as "telegram: <message> (<code>)".
Two specialised subtypes carry extra information:
Matching API errors
Useerrors.Is or the helper tele.ErrIs to match against one of the pre-declared error variables:
Full list of pre-declared errors
General (4xx/5xx)
ErrTooLarge, ErrUnauthorized, ErrNotFound, ErrInternalForbidden (403)
ErrBlockedByUser, ErrKickedFromGroup, ErrKickedFromSuperGroup, ErrKickedFromChannel, ErrNotStartedByUser, ErrUserIsDeactivated, ErrNotChannelMemberMessage errors
ErrCantEditMessage, ErrMessageNotModified, ErrSameMessageContent, ErrEmptyMessage, ErrEmptyText, ErrTooLongMessage, ErrTooLongMarkupFile errors
ErrWrongFileID, ErrWrongFileIDCharacter, ErrWrongFileIDLength, ErrWrongFileIDPadding, ErrWrongFileIDSymbol, ErrCantUploadFile, ErrBadURLContentRights errors
ErrNoRightsToDelete, ErrNoRightsToRestrict, ErrNoRightsToSend, ErrNoRightsToSendGifs, ErrNoRightsToSendPhoto, ErrNoRightsToSendStickers, ErrCantRemoveOwner, ErrUserIsAdminChat errors
ErrChatNotFound, ErrEmptyChatID, ErrGroupMigrated, ErrChatAboutNotModified, ErrChannelsTooMuch, ErrChannelsTooMuchUserHandling flood errors
Handling group migration
Error Handling in Middleware
Middleware can inspect, transform, or suppress errors returned by handlers:Panic Recovery with Recover Middleware
Handlers that panic will crash the goroutine processing the update, taking down that update’s processing. Themiddleware.Recover middleware wraps every handler in a deferred recover:
error-typed panics and string-typed panics, converting them to errors that are then routed through b.OnError (or a custom RecoverFunc).
Best Practices for Production Bots
Always set OnError
The default handler only logs to stderr. In production, route errors to a structured logger or an error-tracking service (Sentry, Datadog, etc.).
Use Recover middleware
Panics in handlers should never crash the bot. Always register
middleware.Recover() globally, before other middleware.Match specific API errors
Don’t treat all API errors the same. Check for
ErrBlockedByUser to clean up stale users, ErrMessageNotModified to suppress noise, and FloodError to implement backoff.Return errors from handlers
Always return errors from handler functions instead of swallowing them with
log.Println. This ensures they flow through OnError and can be centrally tracked.