Performance Problems

When OpenClaw feels slow, uses too much memory, crashes repeatedly, or fills disk with logs, you're dealing with performance and resource issues. This guide covers the five main areas: high memory usage, slow response times, gateway crashes, log file size bloat, and network latency. Start with the quick diagnostic below, then apply the fixes that match your symptoms.

Run openclaw doctor first. The doctor command checks gateway health, config, paths, and resource-related hints. Many performance issues are reported there. See Quick diagnostics for the full flow.

Quick Diagnostic Commands

Use these commands to narrow down performance and resource issues:

# 1. Full health check (do this first)
openclaw doctor

# 2. Apply automatic fixes where safe (dev/test; use with care in production)
openclaw doctor --fix

# 3. Check gateway and service status
openclaw status
openclaw status --all

# 4. Test gateway connectivity
openclaw gateway probe

# 5. View recent or live logs (look for OOM, timeout, high CPU messages)
openclaw logs --tail 50
openclaw logs --follow

# 6. Validate configuration
openclaw config validate

Log file locations: Logs are typically under your OpenClaw data directory (e.g. ~/.openclaw or the path shown by openclaw doctor). Use openclaw logs --tail 50 or openclaw logs --follow to view them without hunting for files.

Performance Issues & Solutions Overview

Below are the performance and resource problems most often reported, aligned with the OpenClaw troubleshooting structure. Each is expanded in the sections that follow.

Symptom	Likely Cause	Solution
High memory usage / OOM	Insufficient RAM, too many skills, or memory leak	Ensure 4GB+ RAM; reduce concurrency or number of skills; check for skill leaks. See High memory usage.
Slow response times	Model latency, network, or overload	Check provider latency and region; reduce load; consider faster model. See Slow response times.
Gateway crashes	OOM, port conflict, or unstable process	Check logs for OOM; ensure single instance; bind to localhost. See Gateway crashes and Gateway issues.
Log file size bloat	Verbose logging, no rotation	Enable log rotation; reduce log level in production. See Log file bloat.
Network latency / timeouts	Firewall, slow provider API, or remote gateway	Check firewall and provider status; use closer region or SSH tunnel. See Network latency.

High Memory Usage

OpenClaw's gateway runs on Node.js and can use significant RAM when handling many channels, skills, or long conversations. If you see out-of-memory (OOM) errors in logs or the process is killed by the OS, the system has run out of memory.

Minimum RAM: For typical setups (one or two channels, a few skills), 4GB RAM or more is recommended. Heavy usage (many channels, many skills, large context) may need 8GB+.
Reduce load: Disable or remove unused skills; reduce the number of concurrent agents or channels if possible.
Check for leaks: If memory grows over time without more traffic, a skill or the core process may be leaking. Update OpenClaw and skills to the latest versions; check Skills issues and community reports.
Docker / VPS: If running in Docker or on a VPS, set memory limits and ensure the host has enough free RAM. See Hosting optimization for resource limits and tuning.

Slow Response Times

If the agent replies slowly, the delay is often from the model provider (API round-trip), not from OpenClaw itself. You can still improve perceived performance.

Provider and region: Use a model provider and region close to your server (e.g. same cloud region as your VPS). Check the provider's status page for latency issues.
Model choice: Faster models (e.g. smaller or optimized variants) can reduce response time. Configure a primary and fallback in model provider setup.
Reduce context size: Very long conversation history or large context windows can slow down inference. Limit context or clear old sessions if supported.
Concurrency: Too many simultaneous requests can queue up. If you have multiple channels or users, ensure the host has enough CPU and that the provider allows your request rate. See Model & API errors for rate limits.

Gateway Crashes

When the gateway daemon exits unexpectedly, check logs for the reason. Common causes include OOM, port already in use, or config errors.

OOM: If logs show out-of-memory or the process was killed (e.g. by the OS), follow the High memory usage steps above.
Port in use: Another process may be using the gateway port. Run lsof -i :3000 (or your configured port) and stop the conflicting process, or change the port in config. See Gateway issues.
Clean restart: Use openclaw stop, wait a few seconds, then openclaw start. Avoid killing the process by hand so the PID file is cleared correctly.
Stability: Keep OpenClaw and Node.js updated. Run openclaw doctor and openclaw doctor --fix (with care in production) to fix permissions or paths that might cause crashes.

Log File Size Bloat

Unrotated logs can fill disk and eventually cause write failures or slowdowns.

Log rotation: Configure log rotation for the OpenClaw data directory (e.g. with logrotate on Linux). Rotate and compress log files by size or date so old logs are archived or removed.
Log level: In production, use a less verbose log level if your deployment supports it (e.g. info instead of debug) to reduce log volume. Check the official docs for configuration options.
Manual cleanup: If disk is already full, remove or archive old log files in the path shown by openclaw doctor. Restart the gateway after freeing space if it failed to start due to disk full.

Network Latency and Timeouts

Slow or failing requests to the gateway or to the model provider often show as timeouts or "provider unreachable" in logs.

Gateway access: If the CLI or channels connect to the gateway over the network, use a fast path: same machine, or SSH tunnel / VPN (e.g. Tailscale) instead of exposing the gateway port publicly. See Security best practices and Gateway issues.
Firewall: Ensure outbound HTTPS to the model provider (e.g. Anthropic, OpenAI) is allowed. Ensure local traffic between CLI and gateway is allowed if they are on the same host.
Provider unreachable: Check the provider's status page; try a different region or fallback provider. See Model & API errors for API and connectivity troubleshooting.

Step-by-Step Debugging

Run health check: openclaw doctor and optionally openclaw doctor --fix (review changes in production).
Check status: openclaw status and openclaw status --all to see if the gateway is running and which config is in use.
Review logs: openclaw logs --tail 100 or openclaw logs --follow while reproducing the issue. Look for OOM, timeout, ECONNREFUSED, or high CPU messages.
Validate config: openclaw config validate to rule out config errors that could cause instability.
Test connectivity: openclaw gateway probe to confirm the CLI can reach the gateway.
Restart cleanly: openclaw stop, wait a few seconds, then openclaw start.

Getting Help

If you're still stuck:

Quick diagnostics - Run doctor and basic checks
Community Hub - Ask in Discord or community channels
GitHub issues - Search existing issues or open a new one

When reporting, include: OpenClaw version, output of openclaw doctor (redact paths and keys), relevant log lines (OOM, timeout, errors), and a redacted config snippet (no API keys).