OpenClaw on Hostinger Stopped Loading | Friends of the Crustacean 🦞🤝 | Page 1

pale quartzBOT Feb 27, 2026, 6:59 AM

#

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

karmic elkBOT Feb 27, 2026, 7:01 AM

#

This usually means the Gateway is no longer healthy (often because a config edit became invalid), so the Control UI can’t complete its websocket connect → you get the “spinner”, and channels stop responding.

On the Hostinger box (SSH), can you run this exact “command ladder” and paste the output (redact any tokens/secrets)?

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

What I’m looking for in the logs/status:

1) Config parse error / bad edit (most common after pasting tokens)

If openclaw gateway status shows it’s restarting/stopped, openclaw logs --follow often shows a JSON/JSON5 parse error pointing at the exact file/line. Fix that line (tokens must be quoted strings; no stray backticks/newlines), then:

#

openclaw gateway restart

2) Gateway auth token got changed (UI spins + “unauthorized” loop)

If the Gateway is running but the UI can’t auth, regenerate/open the correct dashboard URL from the server:

openclaw dashboard

Open the printed URL (it includes the token in the #token=... fragment), or in the UI go to Control → Overview → Gateway Access and re-enter the right Gateway Token/Password (whichever you configured).

3) Channel broke but Gateway is fine

If the UI works but Telegram/others don’t: openclaw channels status --probe will show which channel is failing and why (bad token, webhook/polling error, allowlist/pairing, etc.).

Docs runbook: https://docs.openclaw.ai/gateway/troubleshooting

#

One more thing: if that Telegram bot token was pasted anywhere public/shared, rotate it via BotFather just in case.

Post the outputs (especially gateway status + the first error you see in logs) and we can pinpoint the exact fix quickly.

proud stratus Feb 27, 2026, 7:04 AM

#

karmic elk This *usually* means the Gateway is no longer healthy (often because a config ed...

when I run the openclaw --version command I get openclaw: command not found

karmic elkBOT Feb 27, 2026, 7:05 AM

#

openclaw: command not found means you’re not in an environment where the OpenClaw CLI is on PATH (or you’re SSH’d in as a different user than the one that installed/runs the gateway).

On VPS installs it’s very common that the gateway runs under a dedicated user (often openclaw), so logging in as root / another user won’t have the openclaw command available.

Run these on the Hostinger box and paste the output (no secrets involved):

whoami

# Is it maybe still installed under the old name?
command -v clawdbot || true
command -v openclaw || true

# Find what is actually running + which user is running it
ps aux | egrep -i 'openclaw|clawdbot' | head -n 50

#

Then try (if you see a user like openclaw in the ps output):

sudo -iu openclaw -H bash -lc 'openclaw --version && openclaw gateway status'

If sudo isn’t available, use:

su - openclaw -c 'openclaw --version'

If none of that works, tell me how you installed (installer script vs git checkout vs docker/podman). From a source checkout, the FAQ also notes you may need to run it as:

pnpm openclaw --version

#

Once we can run the CLI, we’ll go straight to openclaw status + openclaw logs --follow to find the exact error causing the dashboard spinner. Docs reference: https://docs.openclaw.ai/gateway/troubleshooting

proud stratus Feb 27, 2026, 7:10 AM

#

I installed this using the one click openclaw installer on hostinger (docker)

karmic elkBOT Feb 27, 2026, 7:11 AM

#

Got it — with the Hostinger one‑click Docker install, openclaw often isn’t installed on the host shell PATH. The CLI you need is usually inside the container, and the fastest way to un-break the “dashboard spinner + no agent replies” is to look at the gateway container logs.

1) Find the running OpenClaw container

SSH into the VPS and run:

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

Look for something like openclaw-gateway (or any container whose image/name contains openclaw).

2) Tail logs (this usually reveals the exact cause)

Replace <name> with the container name from above:

docker logs --tail 200 <name>

#

Common “after pasting a token” failure is a config parse error (JSON/JSON5) which prevents the gateway from starting, so the web UI just spins forever.

3) If you do have a CLI container / compose

Some installs include an openclaw-cli container or a compose file. If you’re in a directory with docker-compose.yml, try:

docker compose ps
docker compose logs --tail 200 openclaw-gateway
# and (super useful):
docker compose run --rm openclaw-cli doctor
docker compose run --rm openclaw-cli status --all

(That doctor run often fixes/points at the broken config.)

4) What I need from you

Paste:

#

output of docker ps ...
the last ~200 lines of docker logs --tail 200 <gateway-container> (redact tokens)

…and I can tell you exactly what to edit/revert to get the gateway back.

Docs reference (Docker flow): https://docs.openclaw.ai/install/docker

Also: if that Telegram bot token was pasted anywhere that others could read, rotate it in BotFather as a precaution.

proud stratus Feb 27, 2026, 7:15 AM

#

WARN: OpenClaw exited with code 0

karmic elkBOT Feb 27, 2026, 7:15 AM

#

That line basically means the gateway process/container is not running anymore (so the dashboard will spin forever because it can’t complete the websocket connect, and channels won’t reply).

On the Hostinger VPS, can you paste these two outputs (redact any tokens if they show up, but usually they won’t):

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}\t{{.Image}}'
docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}\t{{.Image}}'

Then pick the container that looks like the gateway (often named openclaw-gateway or similar) and paste more than the last line:

docker logs --tail 300 <container_name>

Why: “exited with code 0” often happens when the container is accidentally running a one-shot command (CLI/onboard/dashboard) instead of the long-running gateway, or the gateway is deciding to shut down cleanly because it hit a startup guard/config issue — but the real reason will be a few lines above that warning.

#

If you see it’s stopped (not restarting), you can also try a safe restart while we debug:

docker start <container_name>

…but the key is the docker ps -a + docker logs --tail 300 output so we can tell what actually killed it.

proud stratus Feb 27, 2026, 7:21 AM

#

Copyright © 2026 Invoice Ninja. All rights reserved.
<<<END_EXTERNAL_UNTRUSTED_CONTENT id="04cec9ab60f7077a">>>
2026-02-27T05:39:00.140Z [telegram] sendMessage ok chat=8235900814 message=23
2026-02-27T05:39:41.965Z [health-monitor] [whatsapp:default] health-monitor: hit 3 restarts/hour limit, skipping
2026-02-27T05:44:41.966Z [health-monitor] [whatsapp:default] health-monitor: hit 3 restarts/hour limit, skipping
2026-02-27T05:47:56.937Z [telegram] sendMessage ok chat=8235900814 message=25
2026-02-27T05:49:41.969Z [health-monitor] [whatsapp:default] health-monitor: restarting (reason: stopped)
2026-02-27T05:59:41.973Z [health-monitor] [whatsapp:default] health-monitor: hit 3 restarts/hour limit, skipping
2026-02-27T06:04:41.972Z [health-monitor] [whatsapp:default] health-monitor: restarting (reason: stopped)
2026-02-27T06:19:41.971Z [health-monitor] [whatsapp:default] health-monitor: restarting (reason: stopped)
2026-02-27T06:29:41.980Z [health-monitor] [whatsapp:default] health-monitor: hit 3 restarts/hour limit, skipping
2026-02-27T06:34:41.979Z [health-monitor] [whatsapp:default] health-monitor: hit 3 restarts/hour limit, skipping
2026-02-27T06:37:11.284Z [telegram] sendMessage ok chat=8235900814 message=139
2026-02-27T06:39:41.979Z [health-monitor] [whatsapp:default] health-monitor: hit 3 restarts/hour limit, skipping
2026-02-27T06:40:56.547Z [telegram] sendMessage ok chat=8235900814 message=27
2026-02-27T06:43:40.482Z [telegram] sendMessage ok chat=8235900814 message=141
2026-02-27T06:44:41.981Z [health-monitor] [whatsapp:default] health-monitor: hit 3 restarts/hour limit, skipping
2026-02-27T06:46:05.718Z [telegram] sendMessage ok chat=8235900814 message=143
2026-02-26T23:49:09.269-07:00 [tools] exec failed: sh: 1: python: not found

#

Command not found
2026-02-27T06:49:24.700Z [reload] config change detected; evaluating reload (agents.list, bindings, channels.telegram.accounts.eli)
2026-02-27T06:49:24.702Z [gateway/channels] restarting telegram channel
2026-02-27T06:49:24.720Z [reload] config hot reload applied (channels.telegram.accounts.eli)
2026-02-27T06:49:24.998Z [telegram] [claire] starting provider (@ShedSolutionsClaireBot)
2026-02-27T06:49:25.272Z [telegram] [zoe] starting provider (@ShedSolutionsZoeBot)
2026-02-27T06:49:25.335Z [telegram] [default] starting provider (@ShedSolutionsSamBot)
2026-02-27T06:49:25.337Z [telegram] [mark] starting provider (@ShedSolutionsMarkBot)
2026-02-27T06:49:26.884Z [telegram] [eli] starting provider (@ShedSolutionsEliBot)
2026-02-27T06:49:41.980Z [health-monitor] [whatsapp:default] health-monitor: restarting (reason: stopped)
2026-02-27T06:49:45.153Z [ws] ⇄ res ✓ config.get 63ms conn=40424131…74d7 id=7e271fdc…c914
2026-02-27T06:49:45.172Z [ws] ⇄ res ✓ status 84ms conn=40424131…74d7 id=bdad7e05…1586
2026-02-27T06:50:56.703Z [gateway] signal SIGTERM received
2026-02-27T06:50:56.705Z [gateway] received SIGTERM; shutting down
2026-02-27T06:50:56.751Z [gmail-watcher] gmail watcher stopped
[06:50:57] WARN: OpenClaw exited with code 0

karmic elkBOT Feb 27, 2026, 7:22 AM

#

That log chunk doesn’t actually show why the dashboard is spinning — it mostly shows:

WhatsApp health-monitor repeatedly restarting (reason: stopped) and then hitting the “3 restarts/hour” limit
one tool failure: exec failed: ... python: not found (not fatal for the gateway/UI)

To figure out the dashboard spinner we need to confirm whether the OpenClaw gateway container is up and which ports it’s publishing.

Please run these on the Hostinger VPS and paste the output:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}\t{{.Image}}'
docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}\t{{.Image}}'

Then, identify the container that looks like the gateway (often openclaw-gateway), and paste the start + end of its logs:

#

docker logs --tail 2000 <gateway_container_name>

If you have multiple containers and aren’t sure which is which, also paste:

docker inspect --format '{{.Name}}  cmd={{.Config.Cmd}}  entrypoint={{.Config.Entrypoint}}' $(docker ps -aq)

One quick sanity check (from the VPS) once we know the port mapping: can you also tell me what URL you were using for the dashboard before? For Docker installs, the gateway UI is typically on port 18789 (e.g. http://<server-ip>:18789/). If that port isn’t published anymore (or a reverse proxy switched), you’ll get “spinner / wrong app” symptoms.

Once you paste docker ps + the gateway log tail, we can usually spot the exact config/command issue immediately.

#

That log is actually a really good clue:

[gateway] signal SIGTERM received
[gateway] received SIGTERM; shutting down
WARN: OpenClaw exited with code 0

So the gateway didn’t “crash” — it was told to stop (Docker / compose / Hostinger redeploy / someone ran a restart). If it didn’t come back up, the dashboard will spin forever and agents won’t reply.

1) Check whether the gateway container is currently running (and what port it exposes)

On the VPS:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

#

Paste that output.

2) Confirm why it stopped / whether it’s restarting

Once you identify the gateway container name (often openclaw-gateway), run:

docker inspect -f 'name={{.Name}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}} started={{.State.StartedAt}} finished={{.State.FinishedAt}} restartCount={{.RestartCount}}' <container>

If restartCount is 0 and it’s “Exited”, it probably has no restart policy.

3) Bring it back up

If it’s just stopped:

docker start <container>

#

docker logs --tail 200 <container>

If it immediately stops again, the real error will be above the SIGTERM line — grab a bigger slice:

docker logs --tail 2000 <container>

4) One more important thing: are you definitely opening the right dashboard URL/port?

You pasted an “Invoice Ninja” footer earlier — that makes me suspect your browser is hitting the wrong service (e.g. port 80/443), not OpenClaw. The OpenClaw dashboard is usually on port 18789 or whatever shows up under docker ps in the PORTS column.

So: what URL are you opening in the browser (domain + port)?

Paste docker ps output and we can tell you exactly what to open + whether the container is actually alive.

proud stratus Feb 27, 2026, 7:24 AM

#

openclaw-vhki-openclaw-1 Up 45 hours 0.0.0.0:40080->40080/tcp, [::]:40080->40080/tcp ghcr.io/hostinger/hvps-openclaw:latest
NAMES STATUS PORTS IMAGE
openclaw-vhki-openclaw-1 Up 45 hours 0.0.0.0:40080->40080/tcp, [::]:40080->40080/tcp ghcr.io/hostinger/hvps-openclaw:latest

karmic elkBOT Feb 27, 2026, 7:25 AM

#

Nice — that docker ps output means the Hostinger container is running and exposing port 40080:

0.0.0.0:40080 -> 40080

So two very likely issues:

you’re not actually opening the OpenClaw dashboard URL/port (earlier you pasted an “Invoice Ninja” footer, which screams “wrong web app / wrong port / wrong domain”), or
the dashboard loads but the WebSocket handshake/auth is failing, so it sits there “spinning”.

Step 1: Confirm you’re hitting the right thing

From the VPS, run:

curl -I http://127.0.0.1:40080/
curl -s http://127.0.0.1:40080/ | head

#

If that doesn’t look like OpenClaw HTML, you’re pointing at the wrong service.

From your laptop/browser, try explicitly:

http://<your-vps-ip>:40080/ (or http://<your-domain>:40080/)

Step 2 (recommended): Use an SSH tunnel so the UI is “localhost”

This avoids a bunch of origin/pairing/HTTPS weirdness:

On your laptop:

ssh -N -L 40080:127.0.0.1:40080 <user>@<your-vps-host>

Then open:

#

http://127.0.0.1:40080/

Step 3: Check gateway logs for WS/auth errors

Grab anything mentioning ws/unauthorized/origin/1008:

docker logs --tail 500 openclaw-vhki-openclaw-1 | egrep -i 'ws|unauth|origin|1008|pair|device|control' || true

Step 4: If it’s asking for pairing approval (1008)

You’ll need to approve the browser “device”. Try running the CLI inside the container:

docker exec -it openclaw-vhki-openclaw-1 openclaw devices list

If you see a pending requestId:

#

docker exec -it openclaw-vhki-openclaw-1 openclaw devices approve <requestId>

(If openclaw isn’t found inside the container, tell me what that docker exec ... openclaw --version prints and we’ll use the image’s entrypoint/paths instead.)

If you paste the output of the curl checks + the egrep log snippet, I can tell you exactly which of the above it is.

proud stratus Feb 27, 2026, 7:29 AM

#

it was openclaw html. this is what was output
curl -s http://127.0.0.1:40080/ | head
HTTP/1.1 200 OK
X-Powered-By: Express
Cache-Control: no-store, no-cache, must-revalidate
Content-Type: text/html; charset=utf-8
Content-Length: 14436
ETag: W/"3864-0ixzwU6AhawL+KLrvjY1oLpfWvU"
Date: Fri, 27 Feb 2026 07:26:38 GMT
Connection: keep-alive
Keep-Alive: timeout=5

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>OpenClaw</title>
<link rel="icon" type="image/png" href="/assets/openclaw.png">
<style>
* {
margin: 0;
padding: 0;

karmic elkBOT Feb 27, 2026, 7:30 AM

#

Cool — that confirms the Control UI HTML is being served from the container on :40080. So the “spinning wheel” isn’t “can’t reach the server”; it’s almost always the SPA failing to complete the WebSocket connect (auth/device/pairing/origin).

Fastest “get back in” fix: use an SSH tunnel (makes it localhost/trustworthy)

On your laptop:

ssh -N -L 40080:127.0.0.1:40080 <user>@<your-vps>

Then open:

http://127.0.0.1:40080/

Also do it in an incognito/private window (or clear site data) so you’re not fighting a stale token / stale gatewayUrl in localStorage.

This works around the common remote-HTTP problem where the browser can’t do the device-identity flow and the UI just spins.

#

While you load the page, grab the matching gateway log lines

Run this on the VPS in another terminal and then refresh the dashboard:

docker logs -f openclaw-vhki-openclaw-1 | egrep -i 'ws|unauth|origin|1008|pair|device|nonce|signature|control'

If you paste what shows up there, it’ll usually say something explicit like “unauthorized”, “pairing required (1008)”, “device identity required”, etc.

If it says “pairing required (1008)”

You need to approve the browser device. Try running the CLI inside the container:

docker exec -it openclaw-vhki-openclaw-1 openclaw --version
docker exec -it openclaw-vhki-openclaw-1 openclaw devices list

#OpenClaw on Hostinger Stopped Loading

1) Config parse error / bad edit (most common after pasting tokens)

2) Gateway auth token got changed (UI spins + “unauthorized” loop)

3) Channel broke but Gateway is fine

1) Find the running OpenClaw container

2) Tail logs (this usually reveals the exact cause)

3) If you do have a CLI container / compose

4) What I need from you

1) Check whether the gateway container is currently running (and what port it exposes)

2) Confirm why it stopped / whether it’s restarting

3) Bring it back up

4) One more important thing: are you definitely opening the right dashboard URL/port?

Step 1: Confirm you’re hitting the right thing

Step 2 (recommended): Use an SSH tunnel so the UI is “localhost”

Step 3: Check gateway logs for WS/auth errors

Step 4: If it’s asking for pairing approval (1008)

Fastest “get back in” fix: use an SSH tunnel (makes it localhost/trustworthy)

While you load the page, grab the matching gateway log lines

If it says “pairing required (1008)”