Skip to main content
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.

How Handler Errors Flow

When a handler returns a non-nil error, Telebot passes it to the OnError callback that was configured in Settings. If OnError is not set, the default implementation logs the error with the update ID:
The bot does not crash on handler errors. Each update is processed independently and errors are reported, then discarded.

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).
You can also call the error handler manually at any time:

Telebot Error Variables

The telebot package defines sentinel errors for common bot-level failure cases:

Telegram API Error Types

Errors returned from the Telegram API are represented as *tele.Error:
The Error() method formats as "telegram: <message> (<code>)". Two specialised subtypes carry extra information:

Matching API errors

Use errors.Is or the helper tele.ErrIs to match against one of the pre-declared error variables:
Or use a type assertion to inspect the raw fields:

Full list of pre-declared errors

General (4xx/5xx)

ErrTooLarge, ErrUnauthorized, ErrNotFound, ErrInternal

Forbidden (403)

ErrBlockedByUser, ErrKickedFromGroup, ErrKickedFromSuperGroup, ErrKickedFromChannel, ErrNotStartedByUser, ErrUserIsDeactivated, ErrNotChannelMember

Message errors

ErrCantEditMessage, ErrMessageNotModified, ErrSameMessageContent, ErrEmptyMessage, ErrEmptyText, ErrTooLongMessage, ErrTooLongMarkup

File errors

ErrWrongFileID, ErrWrongFileIDCharacter, ErrWrongFileIDLength, ErrWrongFileIDPadding, ErrWrongFileIDSymbol, ErrCantUploadFile, ErrBadURLContent

Rights errors

ErrNoRightsToDelete, ErrNoRightsToRestrict, ErrNoRightsToSend, ErrNoRightsToSendGifs, ErrNoRightsToSendPhoto, ErrNoRightsToSendStickers, ErrCantRemoveOwner, ErrUserIsAdmin

Chat errors

ErrChatNotFound, ErrEmptyChatID, ErrGroupMigrated, ErrChatAboutNotModified, ErrChannelsTooMuch, ErrChannelsTooMuchUser

Handling 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. The middleware.Recover middleware wraps every handler in a deferred recover:
It captures both error-typed panics and string-typed panics, converting them to errors that are then routed through b.OnError (or a custom RecoverFunc).
Register Recover as the first middleware (outermost) with b.Use so it wraps the entire middleware chain. Middleware registered before Recover won’t be protected.

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.

Structured error handling example