OpenClaw Main Adds Recoverable Gateway Suspension and a Channel-Independent Startup Probe
New suspend/resume CLI controls remove a control-plane dead end, while /startupz separates traffic admission from downstream channel health and repairs bundled deployment templates.
OpenClaw has merged two control-plane changes into main that matter to anyone freezing, snapshotting or orchestrating a Gateway: suspension can now be resumed from a fresh client, and /startupz reports whether the Gateway can admit traffic without treating a broken channel account as a failed process.
These are merged source changes, not proof of inclusion in a tagged package. Identify the containing build before changing production probes or suspension automation.
Suspension no longer locks out its own recovery path
The cooperative suspension protocol already fenced new work before a host freeze, but PR #122100 documents a control-plane dead end. Once the Gateway reached prepared, it rejected every new WebSocket upgrade. A fresh CLI or controller therefore could not call gateway.suspend.resume; operators had to use an optional admin HTTP route or wait for the two-minute lease to expire.
Prepared Gateways now accept authenticated WebSocket connections while keeping ordinary methods fenced. Only the gateway.suspend.* control surface remains available. Restart drain, the transient preparing phase, worker ingress and desktop-observe streams stay closed.
The same change adds:
openclaw gateway suspend, including bounded waiting and blocker reporting;openclaw gateway resume <suspensionId>, with idempotent and expired-lease handling; and- a typed client error for rejected WebSocket upgrades instead of an opaque abnormal-close
1006.
Interpretation: suspension now fences work rather than blinding the control plane. That is the right recovery boundary, but it makes authentication on the resume path essential. Do not expose suspension RPCs as unauthenticated emergency controls.
/startupz answers a different question from /readyz
PR #122477 adds /startup and /startupz. They return success only after startup work is complete and while the Gateway is not draining. Downstream channel health is deliberately excluded.
That separates three signals:
| Probe | Operator question |
|---|---|
/healthz |
Is the process alive? |
/startupz |
Has startup completed, and may the platform admit traffic? |
/readyz |
Is the started Gateway healthy including channel-aware readiness? |
Previously, a blocked or disconnected Telegram account could turn /readyz into a platform-level admission failure and remove an otherwise working Gateway and Control UI from service. The new probe lets orchestrators admit the Gateway while channel-aware monitoring still alerts on the broken account.
Remote unauthenticated probe responses expose only bounded status. Version, uptime and pending detail remain limited to local-direct or authenticated callers, reducing build-fingerprinting leakage.
Bundled deployment templates changed too
The merged patch also corrects operational hazards in the bundled examples:
- Fly gains an HTTP check;
- Render stops using pure liveness as traffic admission;
- Kubernetes uses
/startupz, pins an immutable image tag and seeds persisted config only when missing; and - the stale Fly health-check port explanation is corrected.
The Kubernetes config-seeding fix is especially important: an init container that overwrites persisted openclaw.json and AGENTS.md on every start can erase edits made through the product. Treat the new template as a reference diff, not permission to replace your own manifests blindly.
Safe rollout
- Find the exact OpenClaw build containing both landed commits.
- In a disposable environment, suspend and resume from a different authenticated CLI process.
- Freeze longer than the suspension lease and prove admission recovers after thaw.
- While prepared, require ordinary calls to fail with a structured retryable suspension error.
- Break one channel account and prove
/readyzfails while/startupzstays successful. - Start and drain the Gateway and verify
/startupztransitions through503 starting,200 started, then503 draining. - Diff bundled manifests against your production configuration, preserving custom images, secrets, probes and storage ownership.
- Alert on all three probe families separately; do not replace channel monitoring with
/startupz.
Evidence and limits
The upstream PRs report live suspend/freeze/resume proof, lease-expiry recovery, focused Gateway and client suites, startup lifecycle tests, detail-gating checks and deployment-template validation. OpenClaw Academy verified the merged chronology and primary-source claims but did not freeze a production Gateway or deploy the bundled Kubernetes manifest.
Relevant collector records are 53305, 53379, 53404, 53469, 53564 and 53683.
Bottom line
Use /startupz for startup and traffic admission, keep /readyz for channel-aware monitoring, and test suspension recovery from a fresh authenticated process. The two changes make cloud operations substantially less brittle—but only after the containing build and your own manifests pass a controlled rollout.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF