I’ve seen OpenClaw do weird things. Crash without error messages. Respond in the wrong language for no reason. Refuse to acknowledge that a perfectly configured Slack channel exists. Once, it started replying to every message with a haiku. I didn’t ask for haiku mode. There is no haiku mode.
After eight months and approximately 400 “what the hell?” moments, I’ve compiled the 10 problems I’ve seen most often — from my own experience and from helping people in the community Discord. These aren’t theoretical issues from documentation edge cases. These are the things that actually break on real installations.
1. “It Was Working Yesterday” Syndrome
The most common OpenClaw problem isn’t a bug — it’s an API key that expired, a model that got deprecated, or a service endpoint that changed. You didn’t change anything, but something upstream did.
Diagnosis: Check your model provider’s status page first. Then check your API key validity. Then check if the model name in your config still exists. Nine times out of ten, the problem is external.
Fix: Update the key, model name, or endpoint. And set a calendar reminder to check these monthly, because providers change things without emailing you.
2. The Memory Leak That Eats Your Server
After running for a few days, OpenClaw gets slow, then slower, then crashes. Memory usage climbs steadily until the OS kills the process.
Diagnosis: Almost always a conversation context that’s growing without bounds. Each message adds to the context, and if old messages aren’t being pruned, the context eventually consumes all available memory.
Fix: Configure context compaction. Set a maximum context size. Enable automatic pruning of old messages. Restart the service after the fix, and watch memory usage for 24 hours to confirm it stabilizes.
3. Slack/Discord Bot Not Responding
You’ve set everything up, the bot shows “online” in Slack/Discord, but it doesn’t respond to any messages.
Diagnosis: Usually a permissions issue. The bot needs specific permissions (read messages, write messages, read channels) and needs to be invited to each channel explicitly. Another common cause: the webhook URL isn’t reachable from the outside.
Fix: Check bot permissions in the platform’s developer console. Verify the bot is a member of the channel you’re testing in. Test the webhook URL from an external source (use a service like httpbin or requestbin to verify your endpoint is reachable).
4. Cron Jobs Running But Producing Empty Output
Your scheduled job runs on time (you can see it in the logs) but the output is empty or nonsensical.
Diagnosis: The prompt is probably too vague or references data the agent can’t access. “Summarize today’s metrics” fails if the agent doesn’t have access to the metrics database. The job runs, the AI has nothing to work with, and it produces garbage.
Fix: Test the exact prompt as a manual one-off task first. Make sure all data sources are accessible. Include explicit instructions about where to find the data.
5. Responses Are Painfully Slow
Every response takes 15-30 seconds instead of the expected 2-3 seconds.
Diagnosis: Three common causes. First: your conversation context is too large (the model has to process thousands of tokens of history before generating a response). Second: the model API is slow (check the provider’s status). Third: network latency between your server and the API endpoint.
Fix: For context size: enable compaction, limit history length. For API slowness: wait, switch providers temporarily, or use a cached response when possible. For network: consider hosting closer to the API provider’s region.
6. “Rate Limited” Errors
Sudden bursts of 429 errors, or the bot going silent during peak usage.
Diagnosis: You’re exceeding your API provider’s rate limit. This happens when multiple users interact simultaneously, or when a workflow triggers many API calls in quick succession.
Fix: Implement request queuing with rate-limit-aware scheduling. Upgrade your API tier if the free tier is too restrictive. For burst scenarios, add exponential backoff (wait and retry with increasing delays).
7. The Agent Says Things It Shouldn’t
The agent reveals system prompt details, responds inappropriately, or goes off-topic in ways that seem like prompt injection.
Diagnosis: If the agent is exposed to untrusted input (public channels, user messages), prompt injection is likely. Someone crafted an input that overrides your system instructions.
Fix: Add output filtering for sensitive patterns (API keys, system prompt fragments). Implement input validation for known injection patterns. For high-security setups, process untrusted input in a separate context from system instructions.
8. Database Connection Failures
The agent can’t connect to your database, or connections drop intermittently.
Diagnosis: Connection pool exhaustion (too many connections open), authentication issues (password changed, SSL certificate expired), or network issues (firewall blocking, DNS resolution failing).
Fix: Check connection pool settings and increase if necessary. Verify credentials. Test the connection independently (use a database client to confirm you can connect with the same credentials from the same server).
9. File System Permissions
The agent can’t read or write files, even though the paths look correct.
Diagnosis: The OpenClaw process runs under a specific user account. That user account needs read/write permissions to the directories the agent is trying to access.
Fix: Check which user OpenClaw runs as. Verify that user has appropriate permissions on the target directories. On Linux: ls -la to check, chown or chmod to fix. Don’t use 777 permissions — give the minimum access needed.
10. Updates Break Everything
You update OpenClaw, and your carefully configured setup stops working.
Diagnosis: Configuration format changes between versions, deprecated features removed, or dependency conflicts. This is the most frustrating problem because you didn’t change your code — you just wanted the latest features.
Fix: Read the changelog before updating. Back up your configuration before updating. Test the update on a development instance first. If things break, your backup lets you roll back immediately. Never update production without a verified backup and a rollback plan.
The Universal Debugging Approach
When something breaks and you don’t know why:
1. Check the logs (90% of answers are in the logs)
2. Check external services (API status, database connection, network)
3. Check what changed (did you update something? Did the provider change something?)
4. Reproduce the issue (can you trigger it consistently?)
5. Search the community Discord (someone else probably hit this already)
And when all else fails: restart the service and see if the problem goes away. It shouldn’t be the first step, but it’s a valid last resort. Sometimes computers are just being computers.
🕒 Last updated: · Originally published: December 19, 2025