Know when your OpenClaw agent stops responding
As of October 2026 Checked with OpenClaw 2026.10.x Updated
When an OpenClaw agent stops responding, the usual reason is that its Gateway isn't running or isn't connected: the computer slept, lost its network or is mid-update. Less often the agent's turn failed, for example because its AI account needs attention. OpenClaw's health commands tell you which, if you check. Octopus Prime Health Watch checks for you: it marks a Gateway Offline after 120 seconds without a heartbeat and alerts Owners and Admins in the app after 10 minutes.
Why an agent goes quiet
- The Gateway is down. The OpenClaw process stopped, or the machine it runs on is asleep or off.
- The Gateway is up but not connected. The network dropped, or a channel's connection didn't come back.
- An update changed something. OpenClaw updates often, and an update can break a plugin or a channel until it's fixed.
- The turn failed. The model provider refused the request, the account ran out of credit, or the agent's setup has an error.
- It's still working. A long task can take minutes before the first word comes back.
Check it yourself with OpenClaw
On the Gateway host, OpenClaw's health checks answer the first question quickly:
openclaw status: a local summary of whether the Gateway is reachable, its channels and recent activity.openclaw health: the running Gateway's own health snapshot (--jsonfor scripts)./statussent as a chat command: a status reply without running the agent.openclaw logs --follow: what the Gateway is doing right now.
For alerts, OpenClaw exposes HTTP probes (/healthz for "the process is live", /readyz for "ready to take work").
An outside monitoring service can poll them, but only if it can reach a Gateway address, which usually means exposing one.
Trade-off: these work when you're at the machine or have set up monitoring. Nobody is told automatically, and the people who use the agent can't tell "down" from "thinking".
Let Octopus Prime watch it
With Octopus Prime, the channel plugin inside your Gateway keeps one outbound connection open and sends a heartbeat on it. Nothing on your network is exposed, and that heartbeat is what Health Watch reads.
| What happens | What you see |
|---|---|
| No heartbeat for 60 seconds | The Gateway shows as Warning |
| No heartbeat for 120 seconds | Offline, and one incident opens for the outage |
| Offline for 10 minutes | Owners and Admins get an alert in the app (at most one new alert per 30 minutes) |
| An agent misses 2 or more messages in an hour | Owners and Admins get an alert naming the agent |
| Your message gets no answer for 2 minutes | The app says the agent didn't respond, in words that fit the cause, and offers Retry |
| The Gateway comes back | Waiting messages arrive in order, once each; the incident closes after 2 healthy heartbeats |
When an agent is stuck but its Gateway is still connected, Restart Gateway restarts OpenClaw from the app, at most once every 5 minutes. It's off until the Gateway's owner allows it on that computer, needs plugin 1.22.0 or newer, and by default only the person who connected the Gateway can use it. And when an OpenClaw release breaks connections, affected organizations get a short notice, then another when it's fixed.
Health Watch alerts are in the app only, not push or e-mail. It watches; it doesn't start agents or repair Gateways, so a machine that's switched off still needs a person.
A short checklist
- Is the Gateway's computer awake and online? Check Health Watch, or run
openclaw statuson it. - Did OpenClaw or the plugin just update? Restart the Gateway so the update loads (current plugin: 1.39.4).
- Did the agent post a notice about its AI account or setup? Fix that on the Gateway, then Retry.
- Still stuck? The troubleshooting reference lists symptom-first checks your own agent can follow.