Skip to main content
Start with the sandbox itself, then its lifecycle telemetry.

​
Inspect the sandbox

The state field is the observed lifecycle state: requested, reserved, materializing, ready, running, stopped, terminating, failed, terminated, quarantined, or attention. A sandbox that reached failed or quarantined carries a state_reason explaining why; states that need no explanation omit it. The record also reports the resolved image, storage_class, resources, and endpoints.

​
Inspect a command’s outcome

There is no separate execution resource to fetch. hiloop sandbox exec returns the command’s real exit code with stdout and stderr separated, so read them from the invocation itself:
The JSON carries stdout, stderr, exit, and truncated. A truncated of true means output hit the server’s combined output cap, not that the command failed. A command that exceeded its timeout returns partial output with no exit code.

​
Common causes

​
Correlate with telemetry

Every project-backed sandbox records runtime lifecycle events under its run (the run_id returned by sandbox create). That platform timeline is independent of workload capture and answers the questions above without tailing anything:
  • Sandbox slow to start? Read queue_wait_ms on operation.started — it separates time spent queued from time spent provisioning.
  • What failed, exactly? operation.failed carries a stable error.code alongside the operation id you’re polling.
  • Who stopped my sandbox? sandbox.state_changed records each committed transition (state.from → state.to); sandbox.preempted marks an eviction the platform observed but did not request.
Query the same ambient run id across all signals for captured entrypoint, exec, SSH, HTTP, and OTLP activity:
Use the execution response as the source of truth for a buffered command’s output and exit status; captured telemetry is the correlated, queryable record and is best effort by design.