Why is my OpenClaw assistant not responding?

A reply can be lost at four separate points: the instance is not running, the model provider is rejecting the request, the chat integration is not delivering the message, or the network path to the instance is down. Each has a distinct symptom, so the fastest route is to test the layers in order rather than guess. Send a message in the OpenClaw web UI first: if it answers there, the problem is the integration, not the assistant.

My Telegram bot sees direct messages but ignores the group. Why?

Telegram bots are created with Privacy Mode enabled, which means in a group they only receive messages that start with a slash command or that reply to or mention the bot. Every other message is never delivered to your server at all. Turn Privacy Mode off in BotFather under Bot Settings, then remove and re-add the bot to the group so the change takes effect.

My Discord bot never reacts to anything. What is wrong?

Almost always the Message Content Intent. Since 2022 Discord treats the text of a message as privileged data, and a bot without that intent enabled in the Developer Portal receives events with the content field empty. The bot appears online and completely ignores everyone. Enable it under Bot then Privileged Gateway Intents and restart the integration.

The assistant answers in the web UI but not in chat. What does that tell me?

That the instance and the model are both fine, and the problem is entirely in the integration. Check the bot token, whether the bot is actually in the channel, and the platform-specific permissions: Privacy Mode on Telegram, the Message Content Intent on Discord, and an active session for WhatsApp.

Can a bad API key make OpenClaw silent rather than show an error?

Yes, depending on how the reply path is wired. A rejected request from the model provider can surface as an error in the web UI while a chat integration simply produces nothing. If direct messages go unanswered with no visible failure, check the provider first: an expired key, an exhausted credit balance and a rate limit all look identical from the chat window.

How much RAM do I need to run a local model?

More than the entry tier. A 7B model quantised to 4 bits is roughly 4 GB of weights before any context and before the assistant process itself, so the 4 GB plan cannot hold one and the 8 GB plan is the realistic floor. If you deployed on the small tier and pointed OpenClaw at a local model, being killed for memory is the expected outcome rather than a fault.

OpenClaw Not Responding: How to Find Out Why

Name: OpenClaw Self-Hosted AI Assistant Hosting
Brand: Flux
Price: 4.02 USD
Availability: InStock

You send a message and nothing comes back. A self-hosted assistant has four places a reply can go missing, and they look identical from the chat window. Testing them in order takes about five minutes and turns a silent bot into a specific, fixable fault.

The four layers

Before changing anything, know what you are testing. A message travels through all four of these, and any one of them can swallow it without an error reaching you:

The instance. Is OpenClaw actually running on your server?
The model provider. Is the language model accepting your requests?
The chat integration. Is the message reaching OpenClaw at all?
The network path. Can you and the platform reach the instance?

There is one test that splits the problem in half immediately: send a message in the OpenClaw web UI. If you get an answer there, layers one and two are fine and your problem is the integration. If you do not, stop looking at the bot entirely.

Layer 1: is the instance running?

Open your Flux dashboard and check the instance is up rather than restarting in a loop. A container that keeps dying and coming back is the least obvious version of this, because the service looks present between restarts.

The usual cause of a restart loop is memory. If you pointed OpenClaw at a local model rather than a hosted API, the model weights have to fit in the same RAM as everything else. A 7B model quantised to 4 bits is roughly 4 GB of weights on its own, before any conversation context and before the assistant process. On the 4 GB tier that cannot work, and the 8 GB tier is the realistic floor for local inference. Either move up a tier or point the assistant at a hosted model, where the heavy lifting happens on the provider's hardware and your instance only needs to hold the conversation.

If you cannot reach the web UI at all, note that fact and go to layer four before assuming the instance is broken.

Layer 2: is the model provider rejecting you?

OpenClaw is model-agnostic and you bring your own key, which means the most common silence has nothing to do with OpenClaw. Four provider-side failures produce an assistant that stops answering, and from the chat window they are indistinguishable:

The key is invalid or was rotated. Keys get revoked, regenerated and pasted with a trailing space. Re-paste it rather than reading it and deciding it looks right.
The credit balance is empty. Pay-as-you-go accounts stop serving requests the moment the balance runs out, with no warning inside your assistant.
You are being rate limited. New accounts on every major provider sit on low request-per-minute tiers. A burst of messages, or an agent loop that calls the model repeatedly, will hit that ceiling and each rejected request returns nothing useful to the chat.
The model name no longer exists. Providers retire model identifiers, and a configuration written months ago can be pointing at something that has since been withdrawn. The request fails as a bad model rather than as a bad key, which is easy to misread.

Check the provider's own dashboard: usage, billing and rate limit pages tell you in seconds which of the four you have, and all four are fixed there rather than in OpenClaw.

Layer 3: the chat integration

If the web UI answers and the bot does not, the message is never arriving. Each platform has one dominant cause and they are worth knowing by name.

Telegram: Privacy Mode

Bots created through BotFather have Privacy Mode enabled by default. In a group, a bot in that state only receives messages that begin with a slash command, or that reply to or mention the bot directly. Everything else is never delivered to your server, so your assistant is not ignoring people, it genuinely never heard them. This is why the same bot answers direct messages perfectly and appears dead in a group.

To fix it, message BotFather, open Bot Settings for your bot, and turn Group Privacy off. Then remove the bot from the group and add it again, because the setting is applied when the bot joins.

Discord: the Message Content Intent

Since 2022 Discord treats message text as privileged data. A bot without the Message Content Intent enabled still connects, still shows as online, and receives message events with the content field empty. The result is a bot that is unmistakably running and reacts to absolutely nothing.

Enable it in the Discord Developer Portal under your application, Bot, Privileged Gateway Intents, then restart the integration. While you are there, check the bot has permission to read and send messages in the specific channel: channel level overrides quietly beat server level roles, and a bot with server permission can still be mute in one room.

WhatsApp: the session

WhatsApp connections are tied to a linked session rather than a permanent token, and sessions expire, get logged out from the phone, or break when the device is offline for a long period. A silent WhatsApp integration is most often a session that needs re-linking. Re-scan the code and test again before looking anywhere else.

All platforms: the token itself

Whatever the platform, confirm the token in your dashboard is the current one. Regenerating a bot token in the platform's own console invalidates the old one instantly, and it is very easy to regenerate a token while investigating something else and forget to paste the new one back.

Layer 4: the network path

If you reach OpenClaw over Tailscale, the assistant can be perfectly healthy while you simply cannot get to it. Auth keys expire, and device keys expire too, so an instance that has been running untouched for months can drop off your tailnet without anything having failed. Check the Tailscale admin console and confirm the device is still listed and still authorised. If it is not, generate a new auth key and redeploy or reconnect.

This layer explains an otherwise confusing pattern: the bot keeps answering in chat while the web UI is unreachable to you. The instance is fine and running; only your route to it is gone.

It answers, but badly

A slow or truncated answer is a different problem from silence and is usually one of two things. Long conversations eventually exceed the model's context window, at which point requests start failing or the assistant loses the earlier part of the thread. Starting a fresh conversation is the immediate fix. Separately, a large local model on modest hardware is simply slow, and an answer that takes a minute can time out somewhere in the chain before it is delivered. If you need speed on a small instance, a hosted model will beat a local one every time.

The five minute checklist

Send a message in the OpenClaw web UI. An answer there means the problem is the integration; no answer means it is the instance, the provider or your route to it.
Check the instance in your Flux dashboard for a restart loop, and check RAM if you are running a local model.
Check the model provider's own dashboard for an invalid key, an empty balance, a rate limit or a retired model name.
For Telegram, turn off Privacy Mode in BotFather and re-add the bot to the group.
For Discord, enable the Message Content Intent and confirm channel level permissions.
For WhatsApp, re-link the session.
If the web UI is unreachable but chat still works, check Tailscale for an expired device or auth key.

Nearly every case ends at step one, three or four. The pattern worth internalising is that a self-hosted assistant has more moving parts than a SaaS one precisely because you own them, and owning them means the fault is always locatable.