Skip to main content

Troubleshooting

Start here: most failures in Mesa are silent. A bot that is not allowed to answer does not say so — it says nothing at all. So "the bot is ignoring me" is one symptom with several quite different causes, and guessing between them wastes the most time.

The bot does not reply​

Work down this list in order. Each step rules out one cause, and they are ordered by how often they turn out to be the answer.

1. Is this chat authorized, and is this bot assigned to it?​

By far the most common cause, and the one that produces perfect silence.

Two separate checks have to pass: the chat must be authorized for the tenant, and this particular bot must be assigned to it. A bot that works in one group and not another has usually failed the second while passing the first.

Check in the admin console under Channels. Whoever administers your deployment can also confirm it from the logs, where a refusal is recorded as an unauthorized event for the platform, and a bot that is authorized but not assigned appears as bot_not_available — two distinct entries, which is the fastest way to tell the cases apart.

2. Is the integration enabled?​

In the admin console, under Bots, check that the integration exists and is enabled. A disabled integration keeps its configuration and stops processing messages.

3. Is there a working API key?​

A bot with no usable key for its provider cannot generate anything. Under Keys, confirm a key exists for that bot's provider and shows active.

Remember that active only means the last check passed. Keys are validated when added and when someone asks for a re-check — never on a schedule — so a key revoked at the provider will still read active here. If everything else looks right, re-validate the key.

4. Is the credential still good at the platform?​

For Telegram, check the token with BotFather (/mybots). A regenerated token invalidates the one Mesa holds.

For email, remember the credentials are deployment-wide: if email has stopped working for every bot at once, it is the deployment's mail configuration, not any one bot.

5. Is it an email thread waiting on a choice?​

An email thread that matched more than one authorization group produces no reply at all until the person who started it picks a group from the link they were emailed. Only that person can. See Email.

The bot replies, but ignores my attachment​

Working as built. Attachments never reach the model:

  • On Telegram, a photo or file becomes its caption, or a placeholder such as [Photo].
  • On email, attachments are dropped entirely — the bot sees the plain-text body and nothing else.

Put what matters into text. See Conversations.

The bot forgets things​

Check the window size before assuming a bug. The default is the 50 most recent messages; in a busy group that can be a short span of time.

If you have raised the window above 500 and seen no change, that is expected — a second limit caps what is rendered into context at 500 messages regardless. See Context & memory.

And note that Mesa has no long-term memory at all: nothing is carried between conversations, ever.

Replies are slow​

  • Model choice dominates. A smaller model from the same provider is the biggest single lever.
  • A large context window means more to send and more to read. If you raised it, try lowering it.
  • Multi-step execution adds a planning pass and a checking pass per step. It only runs when an agent asks for it, so if it is happening and you do not want it, the fix is in the agent definition rather than a setting.

A screen in the web app is empty or says "Coming soon"​

Several are not built yet, and Home and Groups show sample data rather than yours. Which is which is listed in The web app.

Getting help​