Check these 7 things before you keep Gateway running long term

1. Decide where Gateway actually lives

Make an explicit choice: Gateway runs long term on your local machine, a Linux host, WSL2 or a remote server. Do not start it locally one day and remotely the next while leaving half-finished state on both machines.

2. Keep auth state close to the machine that runs it

Many "works locally but fails remotely" cases are simply provider auth existing only on the local machine. Once Gateway belongs on a remote host, auth, tokens and environment checks should be organized around that host too.

3. Status checks should be the first operating habit

Long-running service management is not "it started once, so it is done." At minimum, get comfortable checking this baseline set regularly:

openclaw health
openclaw gateway status
openclaw logs --follow

Those three commands quickly tell you whether the problem is in the CLI environment, the Gateway process itself, provider auth, or the log side of the system.

4. Do not connect multiple channels at the start

If you add Telegram, WhatsApp and Discord all at once, any early error becomes hard to localize. You cannot easily tell whether the fault is in Gateway, provider auth or a channel-specific pairing and allowlist rule.

A safer order is to stabilize Gateway alone, then add channels one by one.

5. Remote access and tokens belong in the same design pass

As soon as Gateway serves anything beyond local development, authentication tokens can no longer be an afterthought. Plan port exposure, tunnel or LAN access, and token storage or rotation together.

6. Do not wait for an outage before you locate the logs

Many operators only ask where logs are after the first failure. The better pattern is to know the log commands, process-manager log locations and primary troubleshooting entry points before you leave Gateway running.

7. Stabilize the minimum long-running chain before fancy expansion

The correct priority order is simple: Gateway is stable, providers are reachable, health checks are clean, logs are inspectable, and only then do you expand into multiple channels, device fleets or more complex routing.

If you are still somewhere in the first half of that chain, go back to Gateway Overview or Gateway Troubleshooting and tighten the baseline first.