Your Self-Hosted Agent Stopped Responding: Work Down the Stack

Your agent isn’t replying. There’s no error, because from your side there’s nothing to see — you sent a message and nothing came back.

Almost everyone responds by restarting the container. That fixes exactly one of the six or seven things that cause this, and it destroys the evidence for the other five.

Work down the stack instead. Each check below takes seconds, and you stop at the first one that fails.

1. Is the host alive?

ping -c 3 YOUR.SERVER.IP

No reply doesn’t prove the box is down — plenty of providers filter ICMP — so check your provider’s console for the instance state before concluding anything. If the host is genuinely gone, nothing below matters.

While you’re there, look at whether it rebooted recently. uptime on the box will tell you, and an unexpectedly low number reframes everything that follows.

2. Is the process actually running?

docker ps -a --format '{{.Names}}\t{{.Status}}'
# or, if you installed directly
systemctl status openclaw

docker ps -a rather than docker ps — the -a is what shows you containers that have exited, which is precisely the case you’re investigating. A container in a restart loop shows a status like Restarting (1) 12 seconds ago, and that’s a different problem from one that’s simply stopped.

If it’s restarting repeatedly, read the logs before anything else:

docker compose logs --tail=100 openclaw

Configuration errors — a missing token, an invalid API key — usually present as a restart loop rather than a clear message in any UI.

3. Was it killed for memory?

This is the one that produces a completely empty application log, and it catches people repeatedly.

docker inspect <container> --format '{{.State.OOMKilled}} {{.State.ExitCode}}'
sudo dmesg -T | grep -i -E 'killed process|out of memory'

OOMKilled true, or an exit code of 137, means the kernel killed it. The agent didn’t crash and didn’t log anything, because SIGKILL can’t be caught or logged by the process receiving it.

Two things worth knowing if this is your answer. The kernel picks its victim by memory footprint, not by blame — so the thing that got killed often isn’t the thing that caused the shortage. And browser automation is the usual trigger, since a single headless Chromium instance wants 1–2GB to itself. The full OOM diagnosis covers the fix order — swap, container limits, concurrency, then resizing.

4. Is it listening, and on what?

ss -tulpn

Read the Local Address column. If your agent’s port isn’t there at all, the process is up but the service inside it didn’t bind — go back to the logs. If it’s bound to 127.0.0.1 and you’re trying to reach it from elsewhere, that’s working as designed and your reverse proxy or tunnel is the thing to look at.

5. Does it answer locally?

Skip the network and ask the process directly, on the box:

curl -fsS http://127.0.0.1:18789/healthz    # liveness
curl -fsS http://127.0.0.1:18789/startupz   # startup and traffic admission
curl -fsS http://127.0.0.1:18789/readyz     # deep, channel-aware readiness

Those three OpenClaw endpoints answer different questions, and the difference is the diagnosis:

• /healthz passes, /readyz fails → the gateway is fine and a channel is unhealthy. Go to step 6. Don’t restart the gateway; it isn’t the problem.
• All three pass but you get no reply in chat → the agent is healthy and the message never reached it, or the reply never got delivered. Also step 6.
• Nothing answers locally → the process is up but broken. Back to the logs.

If it answers locally but not from outside, the problem is between the two: proxy, firewall, DNS or TLS. Check certificate expiry — an expired certificate produces a hard failure that looks exactly like the app being down.

6. Is the channel still linked?

This is where most “agent stopped responding” cases actually land, because the agent and its messaging channels fail independently.

openclaw channels status --probe
openclaw doctor
openclaw logs --follow

First, don’t over-diagnose silence. OpenClaw’s watchdog deliberately tracks transport activity and application-message activity separately, so a quiet-but-connected session isn’t restarted just because nobody messaged it recently. A silent account is not necessarily a dead one.

Then the channel-specific causes, all of which we’ve documented in detail:

Telegram. getMe returned 401 in the logs means the bot token is wrong or was regenerated. A getUpdates conflict means something else is consuming that token — a second instance still running, or a webhook left registered. If it replies to commands but ignores ordinary group messages, that’s Telegram’s Privacy Mode, which needs /setprivacy and removing and re-adding the bot to the group. Full Telegram troubleshooting.

WhatsApp. If it’s asking for a QR code, the session is gone — most often because the credentials directory wasn’t on a persistent volume and a container recreate took it with it. And a reply appearing in the transcript is not proof of delivery: OpenClaw only counts an auto-reply as sent once the transport returns an outbound message ID, so look for auto-reply delivery failed in the logs. Full WhatsApp troubleshooting.

Both. If you recently moved servers, check nothing is still running on the old box — two instances holding the same channel fight rather than share.

7. Is the model API refusing you?

The agent can be perfectly healthy and simply unable to think.

openclaw logs --follow

Look for 401 (bad or revoked key), 429 (rate limited), or explicit credit and quota messages. Then check the balance on the provider dashboard — an exhausted prepaid balance is one of the most common causes of an agent that responds to nothing while appearing entirely healthy, and it produces no infrastructure symptom at all.

If you’re on bundled credits from a host rather than your own key, that’s the balance to check.

After it’s fixed

Two things worth doing once, so the next occurrence is shorter:

Point monitoring at the right endpoint. Use /startupz for anything that decides whether to restart or route traffic — OpenClaw’s docs are explicit that this prevents “a failed channel account” from removing “the otherwise healthy Gateway and Control UI from service.” Use /readyz for alerting, where you do want to know a channel is down.

Alert on the OOM case, because it’s the one with no application-level signal. A cron job that greps dmesg for kill lines and emails you is five minutes’ work and turns a silent failure into a notification.

If the answer turned out to be memory, size the next box properly: 4GB is the floor for a text-only agent and 8GB once browser automation is involved. Our best VPS for OpenClaw guide covers the brackets.

How we checked this

The health-endpoint semantics (/healthz, /startupz, /readyz and which to use for readiness), the watchdog’s independent tracking of transport and message activity, the getMe 401 and getUpdates conflict signatures, Telegram’s Privacy Mode requiring a remove-and-re-add, and WhatsApp’s delivery-versus-transcript distinction are all from OpenClaw’s own documentation, read in August 2026. The OOM behaviour — exit 137 as 128 plus SIGKILL, and the kernel selecting a victim by memory footprint — is from Docker’s documentation and the Linux kernel documentation respectively.

What we did not do: we did not reproduce each of these failures to time them. This is an ordering of documented behaviours, and the ordering is the point — most of the value here is in checking memory before restarting, and checking the channel before blaming the agent, because both are cases where the instinctive fix destroys the evidence.

This article has no affiliate links. Everything above is a command you already have.

FAQ

My agent stopped responding but the container is running. What now?

Check whether it answers locally with curl 127.0.0.1:18789/healthz. If it does, the agent is healthy and the problem is the messaging channel or the model API — not the container, and restarting it won’t help.

Why is there nothing in the logs?

Because the kernel killed the process. SIGKILL can’t be caught, so the application writes nothing. Confirm with docker inspect --format '{{.State.OOMKilled}}' or by grepping dmesg for OOM lines.

What does exit code 137 mean?

The process received SIGKILL — 137 is 128 plus signal 9. It’s usually the OOM killer, though anything sending SIGKILL produces it, so confirm with State.OOMKilled before assuming memory.

My agent is quiet but shows as connected. Is it broken?

Not necessarily. OpenClaw tracks transport activity separately from message activity precisely so an idle-but-healthy session isn’t restarted. Send an actual message rather than trusting status output, and check delivery in the logs rather than in the transcript.

Why does it reply to commands but ignore normal messages in a group?

Telegram’s Privacy Mode, which is on by default. Disable it with /setprivacy in BotFather, then remove and re-add the bot to the group — the change only applies on re-add.

Could my API key be the problem?

Very often. Look for 401 or 429 in the logs and check your provider balance. An exhausted prepaid balance stops the agent responding to everything while every infrastructure check passes.

What should I check first next time?

Memory, before you restart anything. It’s the only cause on this list whose evidence a restart destroys, and it’s among the most common.