Gateway timeout

[novel ibex]

Intially had gateway timeout errors are resolved in this issue. https://github.com/openclaw/openclaw/issues/47931#issuecomment-4065261047 Having increased the timeout as per the guidance I can now run "openclaw cron list" sucessfully. However I still get a timeout when running "openclaw gateway probe"

Example of cron command failing, BEFORE the issue fix:
$ openclaw cron list

...
Error: gateway closed (1000 normal closure): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/ubuntu/.openclaw/openclaw.json
Bind: loopback

Sucessful example after the issue fix:
$ openclaw cron list

...
ID Name Schedule Next Last Status Target Agent ID Model
6fd33153-504a-41cf-bd45-3dea91651efa check-agentmail cron 0 8-21 * * * @ Europe/Am... in 40m 20m ago ok isolated - -
e4b1f6e2-6d32-4f0d-9a7a-7f4d8bb3a201 Workout Wednesday cron 30 7 * * 3 @ Europe/Amst... in 2d - idle isolated - -
b5c2d7a4-3d1e-4b7f-8c61-2a9f3de8c442 Workout Friday cron 30 7 * * 5 @ Europe/Amst... in 4d - idle isolated - -
9f7afe81-b758-4791-aaf4-f224aae03b3a Workout Monday cron 30 7 * * 1 @ Europe/Amst... in 7d 4h ago error isolated - -

Example of "openclaw gateway probe" even after the fix:
$ openclaw gateway probe

...
Gateway Status
Reachable: no
Probe budget: 3000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - timeout

Hosted on t3a.medium ec2 instance.

[split aspen]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[twilit scaffold]

That output is consistent with the same 3s “handshake budget too aggressive” problem, just in a different codepath:

• openclaw gateway probe shows Probe budget: 3000ms
• it times out before it can complete the WS handshake: Connect: failed - timeout

Meanwhile openclaw cron list can succeed because it’s using a longer timeout/budget (or the patched constant you applied for the cron path), so it’s not a contradiction.

Try this first (usually fixes it)

Run probe with a larger timeout:

openclaw gateway probe --timeout 10000
# or, if the box is under load:
openclaw gateway probe --timeout 30000

If you paste output, use --json (easier to compare targets):

openclaw gateway probe --timeout 30000 --json

If it still times out with 30s

Then it’s not “just slow”; it’s likely not actually reachable on 127.0.0.1:18789 from where the CLI is running (docker/network namespace mismatch, different port, gateway not running, etc.). In that case, please paste:

openclaw --version
openclaw gateway status --json
openclaw status --all

(Version matters a lot here because that 3s default was introduced recently and may be fixed/changed depending on what you’re running.)

Docs reference for probe/timeouts: https://docs.openclaw.ai/cli/gateway#gateway-probe

[novel ibex]

Still fails with 3000 timeout:
$ openclaw gateway probe --timeout 30000 --json
{
"ok": false,
"degraded": false,
"ts": 1773660238836,
"durationMs": 3841,
"timeoutMs": 30000,
"primaryTargetId": null,
"warnings": [],
"network": {
"localLoopbackUrl": "ws://127.0.0.1:18789",
"localTailnetUrl": null,
"tailnetIPv4": null
},
"discovery": {
"timeoutMs": 1200,
"count": 0,
"beacons": []
},
"targets": [
{
"id": "localLoopback",
"kind": "localLoopback",
"url": "ws://127.0.0.1:18789",
"active": true,
"tunnel": null,
"connect": {
"ok": false,
"rpcOk": false,
"scopeLimited": false,
"latencyMs": null,
"error": "timeout",
"close": null
},
"self": null,
"config": null,
"health": null,
"summary": null,
"presence": null
}
]
}

Version: OpenClaw 2026.3.13 (61d171a)

$ openclaw gateway status

🦞 OpenClaw 2026.3.13 (61d171a) — I can't fix your code taste, but I can fix your build and your backlog.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-16.log
Command: /usr/bin/node /home/ubuntu/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 22551, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

[twilit scaffold]

Your --timeout 30000 is being picked up at the top level ("timeoutMs": 30000), but the reason it still fails is visible in the actual probe implementation:

• openclaw gateway probe caps the per-target connect/RPC budget, regardless of the overall timeout.
• For local loopback, the cap is 800ms (and discovery is capped too), so a busy gateway can easily miss that window and you get connect.error="timeout" even though the gateway is otherwise fine.

That’s also why your probe finishes in ~3.8s instead of anywhere near 30s.

What to do instead (reliable reachability check)

Use the commands that don’t have that tiny per-target cap:

openclaw health --json --timeout 30000
openclaw status --deep
openclaw gateway status --timeout 30000

If any of those report reachable / RPC probe: ok, you can treat the gateway as reachable and consider gateway probe a false-negative under load.

Docs: https://docs.openclaw.ai/help/troubleshooting and https://docs.openclaw.ai/gateway/health

Next step for fixing the underlying bug

Can you paste:

openclaw --version

Because this looks like something that should be fixed upstream (either raising/removing the 800ms loopback cap, or making --timeout apply to the per-target probe budget). If you’re up for it, adding your JSON output + the “returns in 3–4s even with --timeout 30000” detail to the GitHub issue you linked would be super useful for getting it addressed.

Yep — that lines up perfectly with 2026.3.13 behavior.

In 2026.3.13, openclaw gateway probe is not “give me up to --timeout to connect”. It has hard per-target caps that stay tiny even if you pass a huge --timeout:

• localLoopback is capped at ~800ms
• “explicit / configured remote” targets are capped at ~1500ms
• (discovery is also capped)

So your JSON showing "timeoutMs": 30000 is the overall budget, but the actual connect attempt for ws://127.0.0.1:18789 still bails quickly — which is exactly why you see durationMs only ~3–4s and connect.error="timeout".

What to use instead (actually respects --timeout)

To validate reachability on a busy gateway, use one of these instead of gateway probe:

openclaw health --json --timeout 30000
openclaw status --deep

openclaw gateway status --timeout 30000

If those succeed, your gateway is reachable — it’s just gateway probe being overly aggressive in 2026.3.13.

Next step (so it gets fixed upstream)

This is worth commenting on in the issue you linked (or opening a new one) with your JSON, because the current gateway probe caps make --timeout kind of misleading under load.

If you run openclaw health --json --timeout 30000 and paste the output, we can confirm everything else is healthy and you can safely ignore gateway probe for now.

Perfect — that openclaw gateway status output is the key bit:

• Runtime: running
• RPC probe: ok
• Listening: 127.0.0.1:18789

So your gateway is definitely reachable and answering RPC. That means openclaw gateway probe is giving you a false negative on 2026.3.13.

What’s happening in 2026.3.13 is basically:

• gateway probe has very aggressive per-target time budgets (loopback is especially tight), so under any gateway load it can miss the window and report Connect: failed - timeout
• gateway status uses a more practical probe path (and you can see it succeeds: RPC probe: ok)

What to do going forward

• Treat openclaw gateway status as authoritative here.
• If you want a JSON health snapshot with a real timeout, use: