OpenClaw Gateway Troubleshooting: 8 Common Errors and How to Fix Them
The OpenClaw gateway is the backbone of your agent system. It routes messages, manages sessions, and keeps your Telegram bots and cron jobs alive. When it breaks, everything stops. This guide covers the eight most common gateway errors, explains why each one happens, and gives you copy-paste fixes to get back online fast.
Why Gateway Errors Happen
The OpenClaw gateway listens on port 18789 by default and acts as the central hub for all agent communication. It handles incoming messages from Telegram and Slack, executes scheduled heartbeat tasks, serves the CLI, and manages session persistence. Because it touches so many systems, there are many places where things can go wrong.
Most gateway errors fall into a few categories: port conflicts, missing environment variables, file permission issues, and configuration mistakes. The good news is that every one of them has a straightforward fix. Below are the eight errors you will encounter most often, in the order you are most likely to hit them.
Error 1: "Gateway Won't Start" - Port 18789 Already in Use
Error: listen EADDRINUSE: address already in use :::18789
This is the single most common OpenClaw error. It means another process is already bound to port 18789. Usually it is a previous gateway instance that did not shut down cleanly, or a second terminal where you accidentally ran openclaw gateway start again.
The Fix
# Find what is using port 18789
lsof -i :18789
# Kill the process using that port
kill $(lsof -ti:18789)
# If it refuses to die, force kill
kill -9 $(lsof -ti:18789)
# Now start the gateway
openclaw gateway startIf you are using pm2, run pm2 delete openclaw before starting fresh. For systemd, use sudo systemctl restart openclaw which handles the cleanup automatically.
To prevent this from happening again, always stop the gateway properly with openclaw gateway stop before closing your terminal, or run it under a process manager like pm2 that handles lifecycle management for you.
Error 2: "API Key Not Found" - Environment Variable Setup
Error: ANTHROPIC_API_KEY is not set. Please set it in your environment.
OpenClaw needs API keys for the LLM provider your agents use. If the environment variable is missing, the gateway starts but every agent call fails. This is especially common when running the gateway as a system service (systemd, launchd) because services do not inherit your shell's environment.
The Fix
# Option 1: Add to your shell profile (~/.zshrc or ~/.bashrc)
export ANTHROPIC_API_KEY="sk-ant-your-key-here"
export OPENAI_API_KEY="sk-your-key-here"
# Reload your shell
source ~/.zshrc
# Option 2: Add to your OpenClaw config
# Create or edit ~/.openclaw/.env
echo 'ANTHROPIC_API_KEY=sk-ant-your-key-here' >> ~/.openclaw/.env
echo 'OPENAI_API_KEY=sk-your-key-here' >> ~/.openclaw/.env
# Option 3: For systemd services, add to the unit file
# Edit /etc/systemd/system/openclaw.service
# Under [Service], add:
# Environment=ANTHROPIC_API_KEY=sk-ant-your-key-here
# Then reload: sudo systemctl daemon-reload && sudo systemctl restart openclaw
# Option 4: For Docker, pass as environment variables
docker run -d \
--name openclaw-gateway \
-e ANTHROPIC_API_KEY=sk-ant-your-key-here \
-e OPENAI_API_KEY=sk-your-key-here \
-p 18789:18789 \
openclaw-gatewayYou can verify the key is set correctly by running openclaw gateway probe which tests the API connection without sending a full agent request.
Error 3: "Session Not Persisting" - JSONL File Permissions and Disk Space
Error: EACCES: permission denied, open '/root/.openclaw/agents/orion/sessions/sessions.json'
OpenClaw stores conversation history in JSONL files inside ~/.openclaw/agents/<name>/sessions/. If the gateway cannot write to these files, sessions are lost between restarts. This usually happens for two reasons: the gateway is running as a different user than the one who owns the files, or the disk is full.
The Fix
# Check file ownership
ls -la ~/.openclaw/agents/
# Fix permissions (replace 'youruser' with your actual username)
chown -R youruser:youruser ~/.openclaw/
# Check disk space
df -h
# If disk is full, clear old session files
# WARNING: This deletes conversation history
rm -rf ~/.openclaw/agents/*/sessions/sessions.json
# Check if the sessions directory exists
ls -la ~/.openclaw/agents/orion/sessions/
# If it does not exist, create it
mkdir -p ~/.openclaw/agents/orion/sessions/On Docker, make sure your volume mount maps to the correct directory inside the container. A common mistake is mounting ~/.openclaw to /root/.openclaw but running the container as a non-root user. The paths must match the user context inside the container.
Error 4: "Telegram Bot Not Receiving Messages" - Webhook vs Polling
Symptom: Bot appears online in Telegram but never responds to messages
OpenClaw supports two modes for Telegram integration: webhook mode and polling mode. Webhook mode requires your gateway to be accessible from the internet on a public URL. Polling mode works behind NATs and firewalls because the gateway reaches out to Telegram. Most local setups need polling mode.
The Fix
# Step 1: Verify your bot token is correct
# Test it directly with the Telegram API
curl https://api.telegram.org/bot[YOUR_BOT_TOKEN]/getMe
# Step 2: Check if a webhook is already set (from a previous setup)
curl https://api.telegram.org/bot[YOUR_BOT_TOKEN]/getWebhookInfo
# Step 3: If webhook URL is set but you are running locally, clear it
curl https://api.telegram.org/bot[YOUR_BOT_TOKEN]/deleteWebhook
# Step 4: For local development, use polling mode
# In your agent config, set:
# "telegram": { "mode": "polling", "token": "YOUR_BOT_TOKEN" }
# Step 5: For production with a public URL, set the webhook
curl -X POST https://api.telegram.org/bot[YOUR_BOT_TOKEN]/setWebhook \
-d "url=https://yourdomain.com:18789/telegram/webhook"
# Step 6: Restart the gateway
openclaw gateway stop
openclaw gateway startA common gotcha: if you previously set a webhook URL and then switch to polling mode, the old webhook intercepts messages before polling can pick them up. Always run deleteWebhook before switching to polling.
Error 5: "Docker Container Crashes on Startup" - Memory Limits and Volume Mounts
Container exited with code 137 (OOMKilled)
Exit code 137 means Docker killed the container because it exceeded its memory limit. The OpenClaw gateway needs at least 512MB of RAM to run comfortably with a few agents. If you are running on a low-memory VPS or have set a tight --memory flag, the container gets killed during agent initialization.
The Fix
# Check container exit reason
docker inspect openclaw-gateway --format='{{.State.OOMKilled}}'
# Run with adequate memory (1GB recommended)
docker run -d \
--name openclaw-gateway \
--restart unless-stopped \
--memory=1g \
-p 18789:18789 \
-v ~/.openclaw:/root/.openclaw \
openclaw-gateway
# Common volume mount issues:
# WRONG - mounts empty directory, gateway has no config
docker run -v /nonexistent/path:/root/.openclaw ...
# RIGHT - mount your actual config directory
docker run -v ~/.openclaw:/root/.openclaw ...
# Check container logs for the real error
docker logs openclaw-gateway
# If the container keeps restarting, check logs immediately
docker logs --tail 50 openclaw-gatewayAnother common Docker issue: the .openclaw directory is not mounted as a volume, so the container starts with zero agent configurations. The gateway runs fine but has nothing to serve. Always verify your volume mounts point to a directory that contains your agent SOUL.md files and config.
Error 6: "Cron Jobs Not Firing" - Gateway Must Be Running
Symptom: Heartbeat tasks configured but agent never executes them
OpenClaw's cron/heartbeat system runs inside the gateway process. It is not a system-level cron job. If the gateway is not running, no scheduled tasks fire. This catches many users who configure heartbeat intervals in their agent's config but forget that the gateway must be running continuously for them to work.
The Fix
# Step 1: Confirm the gateway is running
openclaw gateway status
# Step 2: Check your agent's heartbeat config
# In your agent's config.json, verify the heartbeat section:
# {
# "heartbeat": {
# "interval": "0 */6 * * *",
# "message": "Check for new tasks and report status"
# }
# }
# Step 3: Verify cron syntax is valid
# Use crontab.guru to validate your expression
# Common mistake: "every 6 hours" is "0 */6 * * *", NOT "*/6 * * * *"
# "*/6 * * * *" means every 6 MINUTES
# Step 4: Check gateway health to confirm it can reach the agent
openclaw gateway health
# Step 5: Manually trigger the heartbeat to test
openclaw agent --agent orion --message "heartbeat test"
# Step 6: If the gateway was not running, start it as a daemon
pm2 start "openclaw gateway start" --name openclawIf you need cron jobs to survive gateway restarts, run the gateway under pm2 or systemd. See our Gateway Daemon Guide for setup instructions.
Error 7: "Agent Forgets Context Between Sessions" - Session Keys and WORKING.md
Symptom: Agent responds as if it has never seen your previous messages
OpenClaw agents maintain context through two mechanisms: session files (conversation history) and the WORKING.md file (persistent agent memory). If your agent loses context, one of these is not working properly.
The Fix
# Check if session files exist
ls -la ~/.openclaw/agents/orion/sessions/
# Check if WORKING.md exists and has content
cat ~/.openclaw/agents/orion/WORKING.md
# Verify the session key is consistent
# Each CLI call should use the same session key
# If you are calling from different terminals, specify the session explicitly
openclaw agent --agent orion --session "main" --message "Hello"
# Check that SOUL.md instructs the agent to read WORKING.md
# Your SOUL.md should contain something like:
# "At the start of every session, read WORKING.md for context"
# Check file permissions
ls -la ~/.openclaw/agents/orion/WORKING.md
# The gateway user must have read AND write access
# If WORKING.md is empty or missing, create it
echo "# Agent Working Memory" > ~/.openclaw/agents/orion/WORKING.mdThe most common cause of context loss is using different session keys across calls. If you run openclaw agent from different terminals without specifying a --session flag, each terminal creates its own isolated session. Use a consistent session key for all calls to the same agent.
Error 8: "High API Costs" - Model Selection and Heartbeat Frequency
Symptom: Anthropic/OpenAI bill spikes after deploying agents
This is not an error in the traditional sense, but it is one of the most common complaints from new OpenClaw users. Running agents 24/7 with frequent heartbeats and expensive models can generate significant API costs. The fix is a combination of model selection and heartbeat frequency tuning.
The Fix
# Check current heartbeat interval
# In your agent's config.json:
# "heartbeat": { "interval": "*/5 * * * *" }
# This fires every 5 MINUTES - that is 288 API calls per day per agent!
# Better: every 6 hours
# "heartbeat": { "interval": "0 */6 * * *" }
# That is 4 API calls per day
# Even better: use a cheaper model for routine heartbeat tasks
# In SOUL.md, specify model routing:
# "For heartbeat/routine checks, use claude-3-haiku"
# "For complex tasks, use claude-sonnet-4-20250514"
# Disable heartbeat entirely if you do not need it
# Remove the "heartbeat" section from config.json
# Monitor costs by checking token usage in gateway logs
openclaw gateway status
# Use local models (Ollama) for non-critical agents
# See: /blog/openclaw-ollama-local-agentsCost comparison: Heartbeat every 5 minutes vs every 6 hours
With Claude Sonnet at ~$0.003 per call: 5-minute interval costs ~$0.86/day per agent. 6-hour interval costs ~$0.012/day. That is a 72x reduction for the same agent doing the same job.
Use Ollama for local, zero-cost agents
Agents that do not need top-tier reasoning (monitoring, log parsing, simple automation) can run on local models like Llama 3 or Qwen 2.5 through Ollama. Zero API cost. See our Ollama integration guide.
Essential Debugging Commands
When something goes wrong, start with these three commands. They cover 90% of debugging scenarios.
# 1. Check gateway status and uptime
openclaw gateway status
# Shows: running/stopped, uptime, port, number of active agents
# 2. Test gateway health endpoint
openclaw gateway health
# Tests: HTTP endpoint, API key validity, agent configs loaded
# 3. Deep diagnostic probe
openclaw gateway probe
# Tests: port binding, API connectivity, file permissions,
# session directory access, Telegram webhook status,
# disk space, memory usage
# Additional useful commands:
# Check what is using the gateway port
lsof -i :18789
# View gateway logs in real-time
# (depends on how you run the gateway)
pm2 logs openclaw # pm2
sudo journalctl -u openclaw -f # systemd
docker logs -f openclaw-gateway # Docker
# Test a specific agent without going through Telegram
openclaw agent --agent orion --message "ping"
# Clear all sessions (nuclear option)
rm -rf ~/.openclaw/agents/*/sessions/sessions.json
# Restart the gateway cleanly
openclaw gateway stop && openclaw gateway startQuick Reference: Error to Fix
| Error | Cause | Quick Fix |
|---|---|---|
| EADDRINUSE :18789 | Port conflict | kill $(lsof -ti:18789) |
| API key not found | Missing env var | export ANTHROPIC_API_KEY=... |
| Session EACCES | File permissions | chown -R user ~/.openclaw |
| Telegram silent | Webhook conflict | deleteWebhook + use polling |
| Docker exit 137 | OOM killed | --memory=1g |
| Cron not firing | Gateway stopped | pm2 start openclaw |
| Context lost | Session key mismatch | --session "main" |
| High API cost | Heartbeat too frequent | 0 */6 * * * (not */5) |
Tired of Debugging Gateway Issues?
CrewClaw handles gateway configuration, Docker setup, and environment variables for you. Pick from 103 pre-built agent templates, download a deploy-ready package, and skip the troubleshooting entirely.
Browse 103 Agent Templates103 templates. Zero setup headaches.
Related Guides
OpenClaw Gateway Daemon Guide
Run the gateway as a background service with auto-restart
OpenClaw Docker Deploy Guide
Production Docker setup with volumes and auto-restart
OpenClaw + Ollama Local Agents
Run agents on local models with zero API costs
OpenClaw Cost Optimization
Reduce API spend with model routing and smart heartbeats
Frequently Asked Questions
How do I check if the OpenClaw gateway is running?
Run 'openclaw gateway status' to see the current state of the gateway process. You can also run 'curl http://localhost:18789/health' to test the HTTP endpoint directly. If neither responds, the gateway is not running. Check 'lsof -i :18789' to see if anything is bound to the port, and check your process manager (pm2 status, systemctl status openclaw, or docker ps) to confirm the service state.
Why does my OpenClaw gateway keep crashing after a few hours?
The most common cause is running out of memory. Each agent session consumes RAM, and if you are running many agents with long conversation histories, memory usage adds up. Check your system memory with 'free -h' on Linux or 'vm_stat' on macOS. If memory is the issue, reduce the number of concurrent agents, shorten session history retention, or increase the memory available to your Docker container with the --memory flag. Another common cause is unhandled API errors from your LLM provider. Check the gateway logs for error messages right before the crash.
Can I run the OpenClaw gateway on a different port?
Yes. Set the OPENCLAW_PORT environment variable before starting the gateway. For example: 'OPENCLAW_PORT=19000 openclaw gateway start'. Make sure to update any Telegram webhook URLs, Slack configurations, or reverse proxy settings to point to the new port. If you are using Docker, update both the container's environment variable and the port mapping in your docker run command.
How do I reset the OpenClaw gateway to a clean state?
Stop the gateway first with 'openclaw gateway stop' or by killing the process. Then delete the session files: 'rm -rf ~/.openclaw/agents/*/sessions/sessions.json'. This clears all agent conversation history. Restart the gateway with 'openclaw gateway start'. Your agent configurations (SOUL.md, config files) are preserved. Only the session data is removed.
Skip the Setup. Deploy an Agent in 60 Seconds.
CrewClaw generates your SOUL.md, config files, Docker setup, and deployment scripts. Pick a template, customize it, and download everything you need. No gateway debugging required.
Build Your Agent ConfigFree to generate. $9 one-time to download the full package.
Deploy a Ready-Made AI Agent
Skip the setup. Pick a template and deploy in 60 seconds.