Category 4

Operations and recovery

This is the keep-it-running lane: health checks, drift detection, logs, recovery behavior, and concrete examples of operational intervention.

Use this whenYou are diagnosing problems, recovering stalled work, checking health, or trying to operate OpenClaw like a real system instead of a toy.

Reality checks

Know what is healthy before you touch anything

Before you restart, repair, or report, check what is actually true. Health claims should come from logs, status, running processes, or direct verification, not from assumptions carried over from a previous turn.

Logs, status, and health checksUse evidence instead of vibes.Guardrails and safe recoveryRecover without making the line messier.Runtime drift recoveryFix stalls and recover execution.

Recovery doctrine

The right response to a stall is action

When a job is supposed to keep moving, the operator path is detect, verify, recover, restart. A repeated drift report without intervention is itself a failure state.

Detect

Confirm whether work is genuinely stalled or just quiet.

Repair

Fix the minimum blocker necessary to resume movement.

Resume

Restart immediately and verify that output resumed.

Stall recovery exampleSee the recovery loop in concrete form.Live QA and verificationCheck the real environment after the fix.Healthy quiet vs silent failureDo not confuse calm with broken.

Operating rules

The few rules that keep the system honest

Choose cron when the clock matters. Choose heartbeat when judgment matters. Verify before reporting. During execution mode, keep the work moving instead of drifting back into aesthetic cleanup.

Cron vs heartbeatUse the correct timing mechanism.Verification before reportingGround updates in checks.Execution and stall recoveryKeep work moving until done.

Open the deeper reference links for this category

Full operations lane Full operator examples lane Safe recovery guide