Maintenance API
Check agent health, query runtime state, and trigger maintenance restarts. These endpoints operate on the authenticated user’s deployed agent instance. All lifecycle endpoints (start, stop, restart, repair, reset-memory, update, andPOST /api/openclaw/maintenance) resolve the target Railway service using a two-tier strategy:
- Persisted service ID (preferred) — when the agent’s configuration includes a
runtimeServiceId, the platform uses it directly without making any Railway API calls. This is the default for agents provisioned with the current platform version. - Project-level discovery (fallback) — when no persisted service ID is available (for example, agents provisioned before this feature was introduced), the platform falls back to listing all services in the Railway project and matching by name.
Get instance runtime state
/healthz, /readyz, and /api/status on the agent. This endpoint resolves status without a backend hop — it reads the persisted OpenClaw URL from the database and probes the agent in-process.
Path parameters
Response
Status values
The shared runtime probe uses
/api/status as the authoritative health signal. The legacy /healthz and /readyz endpoints may legitimately return 404 on some deployments. When /api/status returns 200, the agent is considered reachable regardless of legacy probe results.Errors
Get instance stats
/healthz, /readyz, and /api/status. Resource-level metrics (CPU, memory) are not yet exposed by the gateway and return placeholder values.
Path parameters
Response
The
telemetry object is included to signal which metric categories the API supports. All three categories are currently false because the managed runtime does not yet expose restart counts, last-exit details, or per-message telemetry. These fields will transition to true as the underlying runtime adds support.Errors
Start instance
runtimeServiceId when available. When managed runtime controls are disabled, this endpoint returns 503.
Path parameters
Response
Errors
Stop instance
runtimeServiceId when available. When managed runtime controls are disabled, this endpoint returns 503.
Path parameters
Response
Errors
Restart instance
runtimeServiceId when available. When managed runtime controls are disabled, this endpoint returns 503.
Path parameters
Response
Errors
Repair instance
runtimeServiceId when available. When managed runtime controls are disabled, this endpoint returns 503.
The repair uses the user’s per-user gateway token from the database. If no token exists, a new one is generated automatically.
Path parameters
Response
Errors
Reset instance memory
runtimeServiceId when available. When managed runtime controls are disabled, this endpoint returns 503.
Path parameters
Response
Errors
Update instance image
runtimeServiceId when available. When managed runtime controls are disabled, this endpoint returns 503.
Path parameters
Response
Errors
Get instance gateway token
Path parameters
Response
Errors
503 error details
All lifecycle endpoints (start, stop, restart, repair, reset-memory, and update) return503 in two scenarios:
Controls disabled
When managed runtime controls are disabled via theENABLE_OPENCLAW_CONTROLS or NEXT_PUBLIC_ENABLE_OPENCLAW_CONTROLS environment variables, all lifecycle endpoints return:
Service or configuration resolution failure
When the platform cannot resolve the Railway service for the agent, lifecycle endpoints return503 with a descriptive error message. This happens before the lifecycle action is attempted and indicates a configuration problem on the platform side, not an issue with the agent itself.
The platform resolves the Railway service using a two-tier strategy:
- Persisted service ID — when the agent’s configuration includes a
runtimeServiceId(set during provisioning), the platform uses it directly. No Railway API call is made and no project-level listing is needed. This is the default for recently provisioned agents. - Project-level discovery — when no persisted service ID exists, the platform falls back to listing all services in the Railway project and matching by name candidates derived from the agent’s URL and identifier. This fallback requires a Railway token with project-listing permissions.
RAILWAY_API_KEY, RAILWAY_ENVIRONMENT_ID, or RAILWAY_PROJECT_ID). Ensure RAILWAY_TOKEN_TYPE is also set correctly — when using a project-scoped token, set it to project so the platform sends the key via the Project-Access-Token header instead of the default Authorization: Bearer header. The project-listing errors (No managed service reference found and Managed Railway service not found) only occur in the fallback path.
Service resolution errors are distinct from operation errors. A
503 means the platform could not locate the agent’s service to act on. A 500 means the service was found but the requested action (deploy, suspend, restart, or env var update) failed. Agents provisioned with the current platform version include a persisted service ID that bypasses project-level discovery entirely, making the last two error messages unlikely for new deployments.Get agent health
/healthz, /readyz, and /api/status endpoints using the shared runtime probe.
This endpoint uses
GET /api/status on the agent as the authoritative health signal. The legacy /healthz and /readyz probes are still checked for backward compatibility but may legitimately return 404 on some deployments. When /api/status returns 200, the agent is considered reachable even if the legacy probes fail.Response
Status values
Response when no agent is deployed
When the authenticated user has no deployed agent:The health check uses a 5-second timeout for
/healthz and /api/status, and a 4-second timeout for /readyz. When /api/status is reachable but legacy probes fail, the statusReason field explains why the status was derived from /api/status alone.Errors
Restart or reset agent
action field in the request body determines the behavior.
This endpoint resolves the target Railway service using the persisted runtimeServiceId from the agent’s configuration when available, falling back to project-level service discovery for older agents. See service resolution for details.
When managed runtime controls are disabled (via the ENABLE_OPENCLAW_CONTROLS or NEXT_PUBLIC_ENABLE_OPENCLAW_CONTROLS environment variables set to false), this endpoint returns 503 with the message: Managed runtime controls are temporarily disabled until the Railway control path is fully verified.
Request body
Actions
restart (default)
Restarts the agent container. The agent automatically runs openclaw doctor --fix on startup, which performs health checks and applies any pending migrations.
Request:
factory-reset
Pins the agent to the known-good OpenClaw image (v2026.4.11), reconfigures environment variables, and restarts the container with doctor --fix. Use this when an agent is broken after updating to an incompatible version.
Request:
Error responses
When the user has no deployed agent:Factory reset pins the agent to the platform’s configured default image. After a factory reset, you can update to a newer version later through the normal update flow.
Ensure OpenClaw compatibility
Response
Response when no fixes are needed
Error response
When the compatibility check itself fails:This endpoint is idempotent. Calling it multiple times applies only the fixes that have not already been applied. After all fixes are applied, subsequent calls return an empty
fixes array.OpenClaw runtime version
/api/openclaw router applies the authenticate middleware to all non-proxy routes).
The backend normalizes the version before returning it. If the configured image uses a floating tag such as latest, the backend replaces it with the current managed baseline version (2026.4.11) so the response always contains a concrete release number.
Response
OpenClaw runtime version (web proxy)
GET /api/openclaw/version endpoint using the internal API key. Returns the OpenClaw runtime version, container image, and deployment timestamp.
When the backend is unreachable or returns an error, the endpoint returns a fallback version derived from the configured image tag (for example, 2026.4.11) and includes the default image.
Version normalization
All version endpoints — the backendGET /api/openclaw/version, the web proxy GET /api/openclaw-version, and the web-layer GET /api/openclaw/version — normalize the openclawVersion value before returning it. If the configured image uses a floating tag like latest, the version is replaced with the current managed baseline version (currently 2026.4.11).
This ensures every layer of the API returns a concrete release number rather than an opaque tag, so you can reliably compare the running version against known releases.
Response
This endpoint uses an 8-second request timeout when calling the backend. If the backend does not respond within that window, the fallback version is returned. Version normalization now applies at every layer: the backend
GET /api/openclaw/version, the web proxy GET /api/openclaw-version, and the web-layer GET /api/openclaw/version all normalize floating tags to the managed baseline.Heal gateway token
Response
Response when token generation fails
Error response
This endpoint replaces the previous behavior where users had to manually refresh their pairing token. Tokens are now auto-generated when missing. The generated token is a 64-character hex string stored per-user in the database. Lifecycle operations such as repair use the per-user token from the database when reconfiguring the agent runtime.
List OpenClaw instances
Response
Errors
Get instance container stats
Path parameters
Response
Errors
OpenClaw proxy
The proxy rewrites the request path by stripping the
/api/openclaw/proxy/:agentId prefix before forwarding.