Skip to main content
Understanding the runtime lifecycle helps you build agents that stay healthy in production and recover automatically when things go wrong. Knowing what happens at each stage — startup, health checking, failure, recovery — lets you design containers that cooperate with the platform instead of fighting it. This page explains how a Compute instance behaves over its lifetime — from deployment through healthy operation, automatic recovery, and the runtime leases that grant time-bounded execution.

​
Instance states

There is no restarting state. Automatic recovery transitions an instance from failed back to deploying, then to running once health checks pass again.

​
State transitions

​
How deployment works

1

Image pull

The platform pulls the registered Docker image.
2

Start container

The container starts on the assigned tier. AGENT_PORT (default 8080) is injected.
3

Health checks

The platform polls GET /health. Once it returns HTTP 200, the instance transitions to running.
4

Serve traffic

The permanent endpoint begins routing requests to the instance.

​
Automatic recovery

If the underlying infrastructure fails or the instance becomes unhealthy, the platform:
  1. Detects the failure via health checks.
  2. Transitions the instance to failed.
  3. Automatically attempts recovery (re-pulls image, restarts container).
  4. Once health checks pass again, the instance returns to running.
The permanent endpoint stays the same throughout. Callers don’t need to change anything.

​
Runtime leases

For orchestrated execution, the platform allocates resources on your behalf when you submit a task. These resources are time-bounded — if the work completes or times out, they are released automatically. You don’t manage leases directly; the orchestration layer handles them when you submit tasks.

​
Check instance state

The platform runs health checks with a startup grace period. If /health doesn’t return 200 within the grace period, the instance transitions to failed. Exact timeout depends on the tier.
Yes. If recovery fails repeatedly, the instance stays in failed and requires manual intervention (fix the image, then redeploy).
Keep /health cheap and fast (under 100ms). A slow health check can cause false-positive failures during recovery.

​
Errors

​
Common mistakes

  • Treating failed as permanent. Check that the image implements the agent contract and passes /health, then redeploy.
  • Polling for readiness too aggressively. Health checks take a moment after deploying; back off between checks.
  • Heavy work in /health. Health checks run frequently; keep them lightweight.

​
Best practices

  • Make /health return quickly with no side effects.
  • Use redeploy for new revisions so the endpoint stays stable.
  • Monitor instance state and logs during rollouts.

Instances

Deploy and manage instances.

Scaling

Adjust capacity under load.

Logs

Inspect what an instance is doing.

Orchestration

How leases back orchestrated execution.

​
Next steps

Explore the Data Platform to give your agents knowledge and memory.