← NEWS DESK
release impact

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.

Independent operator analysis for people running OpenClaw in production · Editorial standards

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

  1. Find the exact OpenClaw build containing both landed commits.
  2. In a disposable environment, suspend and resume from a different authenticated CLI process.
  3. Freeze longer than the suspension lease and prove admission recovers after thaw.
  4. While prepared, require ordinary calls to fail with a structured retryable suspension error.
  5. Break one channel account and prove /readyz fails while /startupz stays successful.
  6. Start and drain the Gateway and verify /startupz transitions through 503 starting, 200 started, then 503 draining.
  7. Diff bundled manifests against your production configuration, preserving custom images, secrets, probes and storage ownership.
  8. 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.
  1. 01PR #122100: make Gateway suspend/resume operator-usable end to end
  2. 02PR #122477: add /startupz and repair deployment-template admission

THE OPERATOR BRIEF

One useful email when the signal earns it.

Release impact, security changes and repository intelligence. No daily sludge.