Fix OpenClaw "timed out waiting for gateway port 18709"

If OpenClaw fails with “timed out after 60s waiting for gateway port 18709 to become healthy”, the fix is almost always the same three steps: check the gateway status, restart it, and if it is still stuck, clear whatever is sitting on port 18709 and reinstall the service. The gateway daemon never passed its health check in time — usually because a stale process is still holding the port, or another program grabbed it first.

This is a focused deep-dive on one error. For the full list of OpenClaw errors, see the main troubleshooting guide.

What the error actually means

When you start OpenClaw, it launches the gateway daemon and then polls a local port until the daemon answers a health check. The gateway listens on port 18709 by default. OpenClaw gives it 60 seconds. If the port never becomes healthy in that window, you see one of these:

timed out after 60s waiting for gateway port 18709 to become healthy

Another gateway instance already listening

Error: listen EADDRINUSE: address already in use :::18709

All three are the same underlying problem from different angles: the gateway could not own port 18709, so it never went healthy. EADDRINUSE and “another gateway instance already listening” are the explicit causes; the 60-second timeout is what you see when the daemon silently fails to bind.

The fast fix (try this first)

Most of the time this clears it without any port surgery:

openclaw gateway status
openclaw gateway restart

openclaw gateway restart stops the old daemon cleanly and starts a fresh one. That alone resolves the common case where a previous gateway process is still bound to 18709 and the new one is colliding with it. Give it a few seconds, then confirm:

openclaw gateway status
openclaw status --all

If openclaw gateway status reports the daemon healthy, you are done. If it still times out, keep going.

Causes, ranked by how often they bite

Stale gateway: “another gateway instance already listening”

This is the most common cause. A previous gateway run did not shut down cleanly — you closed the terminal, the machine slept, or a crash left an orphaned process bound to 18709. The new gateway tries to bind, finds the port taken by the old one, and times out.

openclaw gateway restart is built to handle exactly this: it stops the existing instance and starts a new one. If a restart does not clear it, the old process is orphaned and OpenClaw can no longer see it — go to the port section below and kill it directly.

If restart fails: force-reinstall the gateway

When openclaw gateway restart keeps timing out, reinstall the gateway service and restart it:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

openclaw gateway install --force re-registers the supervised service (launchd on macOS, systemd on Linux) and rewrites its definition, which clears a half-broken service registration that a plain restart can’t fix. Then confirm with openclaw doctor, which auto-repairs common gateway issues:

openclaw doctor

Find and kill what’s on port 18709

If you still get EADDRINUSE after a clean restart, something other than the current gateway owns the port — an orphaned daemon, a stray Docker container, or an unrelated app. Find it.

macOS and Linux:

# List the process bound to 18709
lsof -i :18709

# Output shows COMMAND, PID, USER... note the PID, then:
kill <pid>

# If it won't die gracefully:
kill -9 <pid>

Windows (PowerShell or cmd):

# Find the PID listening on 18709
netstat -ano | findstr 18709

# The last column is the PID. Kill it:
taskkill /PID <pid> /F

Once the port is free, bring the gateway back up:

openclaw gateway restart
openclaw gateway status

One caution before you kill -9 anything: confirm the PID actually belongs to a gateway or a process you recognize. If lsof points at some unrelated service that legitimately uses 18709 on your machine, killing it is not the fix — you’d want to move that service or change OpenClaw’s gateway.bind, not nuke your other app.

Make it stay healthy: register as a service

If the gateway only times out after a reboot or after you close the terminal, it was never running as a supervised service — it was a foreground process that died with your shell. The durable fix is to register it so the OS keeps it alive and restarts it cleanly:

openclaw gateway install
openclaw gateway status

openclaw gateway install sets up a persistent service: a launchd service on macOS and a systemd unit on Linux. A supervised gateway is restarted by the OS on crash or boot, which eliminates the orphaned-process and stale-port races that cause most port-18709 timeouts in the first place. After installing, openclaw gateway status should report it healthy and survive a reboot.

If it still won’t bind after a clean install, tail the logs while you restart in another terminal — a daemon that crashes on startup will print the real reason there:

openclaw logs --follow

Firewall and binding

A health check that never connects (rather than EADDRINUSE) can also be a firewall or binding problem. The gateway has to be reachable on localhost:18709 for the health poll to succeed.

• On macOS, the application firewall can prompt to allow incoming connections — allow it, or check System Settings > Network > Firewall.
• On Linux, make sure local loopback to 18709 isn’t blocked by ufw/iptables.
• Check your bind mode if you changed it:

openclaw config get gateway.bind

gateway.bind controls where the gateway listens (for example loopback vs LAN). If you set it to a LAN/specific interface that isn’t up, the health check on localhost can fail. For a single-machine setup, the loopback default is the safest.

Quick command sequence

When you hit the timeout, run these in order and stop as soon as openclaw gateway status reports healthy:

openclaw gateway status            # 1. See current state
openclaw gateway restart           # 2. Clean restart (fixes most cases)

openclaw gateway install --force   # 3. Re-register the service
openclaw gateway restart

lsof -i :18709                     # 4. Find the squatter (mac/linux)
kill -9 <pid>                       #    netstat -ano | findstr 18709 on Windows
openclaw gateway restart

openclaw gateway install           # 5. Make it persistent so it stops recurring
openclaw doctor                    #    auto-repair + final sanity check

Related reading

• OpenClaw Not Working? Fix Every Common Error — the full error catalog, including gateway token mismatches and blank responses
• Best local models for OpenClaw — once the gateway is healthy, pick a model that tool-calls reliably
• Best local LLM by RAM — match a model to your hardware

Need help?

If the gateway still won’t go healthy after working through this — or you’d rather not debug launchd/systemd yourself — I can fix it with you on a live session. See how 1:1 OpenClaw help works.