The process came back. The business may not have.
OpenClaw published v2026.7.1-beta.6 on July 13, 2026. It is explicitly a pre-release, so the notes are not evidence of audited uptime or proof that every recovery edge works in production. They are useful for a different reason: the release reads like a list of ways an autonomous operation can return from a restart looking healthy while quietly losing, repeating, or misreporting work.
The release says container migrations now finish before the Gateway reports readiness. Repeated unclean starts can move it into a control-plane-safe mode while transports and model providers stay inactive. Fatal configuration errors stop restart flapping. Queued delivery replays are paced after startup so the outage backlog does not immediately collide with channel rate limits. Several fixes stop the system from reporting success when a turn was not durably adopted, a delivery only partly succeeded, or the send result remained unknown.
This is the commercially important layer below the agent demo. A payroll run, customer reply, claim update, purchase, or scheduled report does not care that a process restarted. The customer cares whether the right obligation resumed, whether an external action happened once rather than twice, and whether the system admitted uncertainty instead of manufacturing a green checkmark.
Alive is not ready
OpenClaw's current Gateway documentation, accessed July 13, separates liveness from usable readiness. Its `/healthz` endpoint can answer when the server is alive; `/readyz` stays red while plugin sidecars, channels, or configured hooks are still settling. The new pre-release goes further after repeated bad boots: keep a control surface available for recovery, but hold back the machinery that can receive or send work.
That distinction belongs in an autonomous-business product, even if the implementation is not OpenClaw. The control plane is where an operator inspects queues, disables a workflow, changes a credential, views the last checkpoint, or chooses manual handling. The execution plane is where the agent calls tools and changes customer state. If both disappear together, the rescue procedure begins with locating a person who still remembers the password. This is considered traditional.
Do not mark the business ready because the model endpoint answered once. Readiness should include the queue store, required tools, identity and permission checks, delivery channels, current workflow version, and the systems that verify completion. During degraded service, keep intake and status honest while side effects remain blocked. A useful red light is better than a busy green one.
Resume the record, not the model's mood
OpenClaw's restart-recovery page, accessed July 13, specifies what it expects to survive: conversations, transcripts, scheduled jobs, background-task records, and queued outbound messages. A requested restart stops admitting new work and drains active work for up to five minutes by default. Interrupted sessions can be marked at admission, shutdown, or the next startup scan. Recovery then retries up to three times with exponential backoff while reusing one durable dispatch identifier.
The safety limits matter more than the cheerful word resume. OpenClaw checks the transcript tail before continuing; a stale pending approval produces a request to resend rather than a blind replay. Reconstructed code work is restricted to audited read-only or explicitly replay-safe tools. Subagent runs interrupted more than two hours earlier are finalized instead of resurrected, and repeatedly unrecoverable sessions are marked wedged. Old work should not wake up surprised and start emailing people.
OpenAI's current Agents SDK human-in-the-loop guide describes a similar state problem from the developer side. A paused run can be serialized, stored while the server is off, and resumed later. The restoring process still has to rebuild the same agent graph, and OpenAI recommends storing the operator's own code version with long-lived state so it can be restored against the correct implementation. Serialized context can also contain application data, so persistence needs a secrets policy, not merely enthusiasm for JSON.
Maybe sent is a real operating state
The dangerous restart does not happen neatly before or after an action. It happens after the agent asks another system to send the email, create the refund, update the record, or place the order, but before the acknowledgement returns. The local process knows it lost a connection. It does not know whether the outside world changed. Retrying may complete the job or repeat it.
OpenClaw's July 13 notes describe an outbound guard built around that distinction. When a connection or DNS failure proves that no request left, stale send evidence can be cleared and the queued message can replay. When delivery remains unknown, the duplicate guard is preserved. Stripe's current low-level error guide makes the same point in the expensive dialect of payments: after a network error, reuse the same idempotency key and the same parameters to seek a definitive result; treat a 500 response as indeterminate because the original request may have produced side effects; reconcile later events against a local identifier.
An autonomous business therefore needs more than completed and failed. A practical ledger includes not started, running, waiting for approval, external result unknown, committed, verified, failed, and expired. Committed means the target system accepted the change. Verified means the customer-visible result passed its acceptance check. Those are different states. Support departments have been built from the space between them.
Write the restart contract
Start by labeling every workflow step. Read-only steps may be replayed if their inputs and versions are pinned. An idempotent write may be repeated with the same operation key and parameters, but only when the receiving system honors that key instead of applying a second business effect. A compensatable action has an explicit reversal. An irreversible action needs a smaller permission boundary, stronger evidence, and usually a person before execution. Calling every tool retry safe in a diagram does not improve the tool.
For each job, persist a business identifier, customer or case, workflow and code version, input reference, current checkpoint, approval state, external idempotency key, attempt count, deadline, and owner. Record the request sent to each external system, any response or receipt, the before-and-after state used for verification, and the customer-visible delivery result. Keep the job record outside the disposable worker that is doing the job. A transcript can explain what the model said. It cannot by itself prove what the bank, CRM, inbox, or warehouse did.
Then define recovery policy before the first incident. Which states replay automatically? How old can a job be before it expires? Which queue drains first? How quickly may the backlog re-enter customer channels? When does the system notify the customer, switch to a human, or open a reconciliation case? Recovery traffic should be paced and observable. An outage backlog is not pent-up productivity. It is a stack of old promises with access to production tools.
The operator takeaway
Founders should run three recovery drills on one revenue-bearing workflow. Kill the worker before an external write. Kill it after the external system commits but before the receipt is stored. Then pause it for approval, deploy a new workflow version, and try to resume the old state. The test passes only if the job is either completed and verified, held for explicit review, or expired with an owner. Restarting the process is setup, not success.
Buyers should request the last 90 days of interrupted jobs, recovery attempts, successful resumptions, jobs declared stale, duplicate side effects, partial deliveries, unknown outcomes, manual resend requests, reconciliation minutes, and oldest queued work. Ask for the actual restart drill and one case that failed it. A dashboard showing 99.9% model availability says very little about whether a purchase, reply, or account change happened twice.
Operators should track recovery success rate, time from process start to workflow readiness, queue age, replay volume, duplicate suppression, wedged jobs, manual interventions, and the count and age of indeterminate side effects. Recovery maturity shows up in the obligation ledger: every interrupted job resumes safely, stops for review, or expires with a named owner. A green process monitor settles none of those debts.
A recovered process proves that the server came back. A recovered obligation proves that the business did.
The difference is a ledger, a replay rule, and someone assigned to the word unknown.
- openclaw 2026.7.1-beta.6OpenClaw / GitHub, accessed July 13, 2026
- Restart recoveryOpenClaw, accessed July 13, 2026
- GatewayOpenClaw, accessed July 13, 2026
- Human-in-the-loopOpenAI Agents SDK, accessed July 13, 2026
- Advanced error handlingStripe, accessed July 13, 2026