How to Run an OpenClaw Rescue Bot

A rescue bot is the operator lane you want when the main OpenClaw bot is misconfigured, overloaded, or unreachable. Instead of trying to debug the broken system from the same broken channel, you run a second isolated Gateway profile with its own bot token and port. It is small insurance for anyone depending on OpenClaw in production.

30-second answer

Use a separate profile such as rescue, a separate Telegram bot, a separate workspace/state/config, and a different base port such as 19789. The official quickstart is openclaw --profile rescue onboard followed by openclaw --profile rescue gateway install --port 19789 if onboarding did not already install the service.

When this pays off

This pays off when your main agent stops replying, a config change blocks startup, a channel token expires, or you need a clean DM path to inspect logs and status. For agencies and founders, a rescue bot reduces downtime risk without needing a full operations team. It is the difference between panic and a known backdoor that is still controlled.

Operator runbook

1. Create a separate Telegram bot or equivalent channel identity. The docs recommend a completely separate Telegram bot for the rescue profile because it is easy to keep operator-only, has its own token, and remains independent when the main bot channel install is broken.
2. Onboard the rescue profile. Run openclaw --profile rescue onboard. During onboarding, keep the rescue profile, use the separate bot token, and accept a separate rescue workspace unless you already manage one deliberately. The profile boundary is what gives the rescue lane its value.
3. Use a unique base port. The guide suggests 19789 for rescue when main uses 18789, and says to leave at least 20 ports between base ports so derived browser, canvas, and CDP ports do not collide. Adjacent ports are a subtle future failure.
4. Install the service only if needed. If onboarding already installed the rescue service, do not duplicate it. Otherwise run openclaw --profile rescue gateway install --port 19789. Keep service names and launch entries profile-specific so restarts do not hit the wrong Gateway.
5. Keep credentials and state separate. A rescue bot should not share OPENCLAW_STATE_DIR, workspace, browser profile, or channel credentials with the main bot. It can inspect and help you recover, but it should not create new races against the broken control plane.
6. Limit the rescue bot audience. Pair only trusted operators and keep the channel private. A rescue bot often needs sensitive visibility, so treat it like emergency infrastructure rather than a second general-purpose assistant.

Verification

Check openclaw gateway status for the main profile and openclaw --profile rescue gateway status for the rescue profile. Then send the rescue bot a DM and confirm it answers independently. Finally, verify both profiles use different ports and that a main Gateway failure does not stop the rescue DM path.

Common mistakes

Do not run rescue on the same port, same Telegram bot, or same state directory. Do not give the rescue lane broad public group access. And do not forget to document it; an emergency-only bot that nobody remembers how to reach is just unused complexity.

Turn it into a repeatable operating system

The Playbook treats rescue access as an ops pattern: named profile, named port, narrow tools, private channel, and a checklist for inspecting the main bot without making the outage worse. It is not glamorous, but it is exactly the kind of boring reliability that keeps revenue workflows alive.

Before rollout

Before rollout, rehearse the rescue path while the main bot is healthy. Send the rescue DM, check status for both profiles, and confirm the rescue bot can reach logs or diagnostics without sharing the broken profile state. Emergency tools should be boring before the emergency.