Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
Standardize handling of common OpenClaw errors (gateway restart, browser service unavailable, cron failures) with automated recovery steps. Use when you need...
Standardize handling of common OpenClaw errors (gateway restart, browser service unavailable, cron failures) with automated recovery steps. Use when you need...
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run.
This skill provides patterns for automating the detection and recovery of common OpenClaw errors: gateway unresponsiveness, browser service failures, cron scheduler issues, and other recurring problems. It builds on health‑monitoring and system‑diagnostics by adding automated recovery workflows that can be triggered by cron jobs, heartbeat checks, or external monitoring.
A service (gateway, browser, cron) fails intermittently and you want to automate its restart. You are setting up proactive monitoring and need a recovery plan beyond just detection. You want to reduce the manual steps required when “Läuft alles?” reveals a failure. You need to ensure critical OpenClaw components stay running with minimal user intervention. You are asked to “create a skill for error recovery automation” (this is that skill).
Before automating recovery, you must reliably detect the error. Use these detection methods: Gateway unresponsive: openclaw gateway status returns non‑zero exit code or shows "running": false. Gateway logs (~/.openclaw/logs/gateway.err.log) contain recent CRITICAL or ERROR entries. HTTP health endpoint (if configured) returns non‑2xx status. Browser service unavailable: openclaw browser --browser-profile openclaw status --json shows "running": false or CDP not ready. Browser logs contain connection timeouts or Chrome process failures. Simple page load via curl to CDP endpoint fails. Cron scheduler not running: openclaw cron status returns "running": false or error. Cron logs show no recent activity. Scheduled jobs are not triggered (check openclaw cron list for missed runs). Memory search disabled: memory_search tool returns “disabled” or native‑module error. openclaw doctor --fix reports better‑sqlite3 mismatch. Permission errors: File operations fail with EACCES/EPERM. Logs indicate permission denied on specific paths (archive, logs, config).
For each error type, define a recovery script that attempts to restore service automatically. The script should: Detect the error (using the patterns above). Attempt recovery (restart service, fix permissions, rebuild module). Verify recovery (re‑run detection after a short wait). Report outcome (exit code 0 for success, non‑zero for persistent failure). Gateway Recovery Script Template #!/bin/bash set -e SERVICE="gateway" MAX_ATTEMPTS=2 SLEEP_SECONDS=5 log() { echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*"; } check() { openclaw gateway status > /dev/null 2>&1 } restart() { openclaw gateway restart sleep "$SLEEP_SECONDS" } attempt=0 while [ $attempt -lt $MAX_ATTEMPTS ]; do if check; then log "$SERVICE is healthy" exit 0 fi log "$SERVICE is unhealthy, restarting (attempt $((attempt+1))/$MAX_ATTEMPTS)..." restart ((attempt++)) done log "$SERVICE could not be recovered after $MAX_ATTEMPTS attempts" exit 1 Browser Service Recovery Script Template #!/bin/bash set -e SERVICE="browser" PROFILE="openclaw" MAX_ATTEMPTS=2 SLEEP_SECONDS=8 log() { echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*"; } check() { openclaw browser --browser-profile "$PROFILE" status --json 2>&1 | grep -q '"running":true' } restart() { openclaw browser --browser-profile "$PROFILE" stop sleep 2 openclaw browser --browser-profile "$PROFILE" start sleep "$SLEEP_SECONDS" } attempt=0 while [ $attempt -lt $MAX_ATTEMPTS ]; do if check; then log "$SERVICE ($PROFILE) is healthy" exit 0 fi log "$SERVICE ($PROFILE) is unhealthy, restarting (attempt $((attempt+1))/$MAX_ATTEMPTS)..." restart ((attempt++)) done log "$SERVICE ($PROFILE) could not be recovered after $MAX_ATTEMPTS attempts" exit 1 Cron Scheduler Recovery Script Template #!/bin/bash set -e SERVICE="cron" MAX_ATTEMPTS=1 SLEEP_SECONDS=3 log() { echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*"; } check() { openclaw cron status 2>&1 | grep -q '"running":true' } restart() { # Cron is restarted automatically when gateway restarts. # If cron is not running, restart gateway. openclaw gateway restart sleep "$SLEEP_SECONDS" } attempt=0 while [ $attempt -lt $MAX_ATTEMPTS ]; do if check; then log "$SERVICE scheduler is running" exit 0 fi log "$SERVICE scheduler is not running, restarting gateway (attempt $((attempt+1))/$MAX_ATTEMPTS)..." restart ((attempt++)) done log "$SERVICE scheduler still not running after $MAX_ATTEMPTS attempts" exit 1 Memory Search Recovery Script Template #!/bin/bash set -e SERVICE="memory_search" MAX_ATTEMPTS=1 log() { echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*"; } check() { openclaw memory search --query "test" 2>&1 | grep -q -v "disabled\|Module did not self-register" } restart() { # Try rebuilding better‑sqlite3 cd "$(dirname "$(which openclaw)")/../lib/node_modules/openclaw" npm rebuild better-sqlite3 # Restart gateway to pick up the rebuilt module openclaw gateway restart sleep 5 } attempt=0 while [ $attempt -lt $MAX_ATTEMPTS ]; do if check; then log "$SERVICE is functional" exit 0 fi log "$SERVICE is disabled, rebuilding native module (attempt $((attempt+1))/$MAX_ATTEMPTS)..." restart ((attempt++)) done log "$SERVICE could not be recovered after $MAX_ATTEMPTS attempts" exit 1
Once you have a recovery script, schedule it as a cron job that runs only when the service is likely to fail (e.g., every 30 minutes for browser, every hour for gateway). Use an isolated agent session to execute the script and announce failures. Example cron job for browser recovery: openclaw cron add \ --name "Browser‑Recovery‑Automation" \ --schedule 'every 30 minutes' \ --session isolated \ --payload '{"kind":"agentTurn","message":"Run browser recovery automation script","model":"default","thinking":"low"}' \ --delivery '{"mode":"announce","channel":"telegram"}' Agent response inside isolated session: The agent reads the script (or inline logic) and executes it via exec. If the script exits with 0, the agent announces success; if non‑zero, the cron delivery forwards the failure message. Alternative: You can embed the recovery logic directly in the agent’s response (without a separate script) for simplicity, but a script is easier to test and reuse.
If automated recovery fails after the maximum attempts, escalate: Log the failure in memory/YYYY‑MM‑DD.md with tag error‑recovery‑failed. Add a task to inbox/agent‑aufgaben.md for manual diagnosis. Send a high‑priority notification (if supported) to the user. Fallback to a safe state (e.g., disable the problematic component if possible). Example escalation snippet: if [ $? -ne 0 ]; then echo "Browser recovery failed. Adding manual diagnosis task." # Append to agent-aufgaben.md echo "| 99 | Diagnose browser recovery failure – automated recovery failed after 2 attempts | ⬜ |" >> inbox/agent-aufgaben.md # Store in memory echo "## [error] Browser recovery automation failed" >> memory/$(date +%Y-%m-%d).md echo "Date: $(date +%Y-%m-%d)" >> memory/$(date +%Y-%m-%d).md echo "Tags: error, browser, recovery-failed" >> memory/$(date +%Y-%m-%d).md echo "Browser recovery script exited with code $?. Manual intervention required." >> memory/$(date +%Y-%m-%d).md fi
Before deploying a recovery script as a cron job, test it manually: Simulate the failure (e.g., kill the gateway process, stop the browser service). Run the recovery script and verify it detects the failure and restarts the service. Check that the service is functional after recovery. Verify logs for any unintended side effects. Example test command: # Stop browser service openclaw browser --browser-profile openclaw stop # Run recovery script ./scripts/browser-recovery.sh # Verify browser is running openclaw browser --browser-profile openclaw status --json | grep '"running":true'
Script: scripts/gateway-recovery.sh (see template above). Cron schedule: every 1 hour. Announce only on failure.
Script: scripts/browser-recovery.sh (see template above). Cron schedule: every 30 minutes. Announce only on failure.
A single script that checks multiple services and recovers any that are unhealthy. Useful for a comprehensive “keep‑alive” cron job. #!/bin/bash set -e log() { echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*"; } # Check gateway if ! openclaw gateway status > /dev/null 2>&1; then log "Gateway unhealthy, restarting..." openclaw gateway restart sleep 5 fi # Check browser if ! openclaw browser --browser-profile openclaw status --json 2>&1 | grep -q '"running":true'; then log "Browser unhealthy, restarting..." openclaw browser --browser-profile openclaw stop sleep 2 openclaw browser --browser-profile openclaw start sleep 8 fi log "All services healthy" exit 0 Schedule this script every 30 minutes with an isolated agentTurn job.
Over‑aggressive recovery: Restarting a service too frequently can cause instability. Set reasonable intervals (≥30 minutes) and maximum attempts (≤2). Silent recovery: If recovery succeeds but you never hear about it, you might not know the service was failing. At minimum, log recovery events to memory/ files. No verification: Restarting a service without verifying it actually recovered can mask deeper issues. Always re‑check after restart. Hard‑coded assumptions: Avoid assuming a specific Node version, path, or user ID. Use environment variables or detect them at runtime. Ignoring dependencies: Browser depends on gateway; restarting browser while gateway is down will fail. Check dependencies in order. Automating unsafe actions: Do not automate deletion of logs, modification of critical configs, or any irreversible action without a rollback plan.
Health‑Monitoring skill – proactive health checks and monitoring. System‑Diagnostics skill – diagnosing root causes of failures. Cron‑Job Creation playbook – creating scheduled jobs. Gateway Health Check and Recovery playbook – specific to gateway. Browser Service Health Monitoring and Recovery playbook – specific to browser. Maintenance Execution playbook – incorporating recovery into regular maintenance.
scripts/gateway-recovery.sh (template) scripts/browser-recovery.sh (template) scripts/cron-recovery.sh (template) skills/health-monitoring/SKILL.md skills/system-diagnostics/SKILL.md docs/MAINTENANCE.md memory/patterns/playbooks.md openclaw cron --help openclaw gateway --help openclaw browser --help
When an OpenClaw error occurs (gateway, browser, cron, memory search), read this skill to create or run an automated recovery script. Store successful recovery patterns in memory/patterns/tools.md. Update pending.md if automation fails and manual intervention is needed. This skill increases autonomy by providing standardized, automated recovery workflows for common failures, reducing the need for manual intervention and increasing system resilience.
Code helpers, APIs, CLIs, browser automation, testing, and developer operations.
Largest current source with strong distribution and engagement signals.