Fleet-wide rollup of instance-agent health and version.
curl --request GET \ --url https://stratum.example.com/v1/admin/compute/instance-agents/summary \ --header 'Authorization: Bearer <token>'Operator endpoint. Counts in-VM agent health and version drift across every project in one call.
It exists because every other agent-state source is project-scoped. Building
this in a client would mean enumerating projects and fanning out one
inventory call each — which does not scale, and is not even “all tenants”:
/v1/projects returns the projects the caller can see, so an operator view
assembled that way silently under-reports the fleet it is meant to cover.
Install-scoped, like the other /v1/admin/compute/* endpoints.
Authorizations
Section titled “Authorizations”Responses
Section titled “Responses”Fleet agent rollup.
Fleet-wide rollup of in-VM agent health and version, across every project.
object
The agent build this control plane serves. Empty when it cannot resolve one — in which case every version comparison below is meaningless, and instances are reported as on-version rather than stale so a missing build number cannot fabricate a fleet-wide incident.
Live (non-terminated) instances across all projects.
Health counts, derived from the last heartbeat with the same threshold the per-instance agent-status endpoint uses.
object
Reported within the heartbeat window.
Previously seen, but silent for longer than the window.
Never reported at all. Usually an agent that was never installed — the population this page exists to surface. Disabled and pending-enrollment agents are not counted here.
Instances whose agent is disabled (agentEnabled false);.
Instances with the agent enabled whose install command has not been run yet;.
Instances whose reported agent build matches servedVersion.
Instances reporting a DIFFERENT build. Note onServedVersion + onOtherVersion does not equal total: an agent that never reported has no version to compare and is in neither bucket, so the shortfall is the never-reported set.
Instances that are BOTH on a different build AND not healthy — the number to act on. Each half alone is noise: a node one build behind between deploys is normal, and a healthy agent on an old build is a rollout lagging rather than an incident.
Example
{ "servedVersion": "v0.0.0-c4722d14"}Authenticated but not authorized.
object
The findings of a rejected IAM policy document (custom and resource policies).
One finding of a rejected IAM policy document. A rejection lists every finding, so the author fixes the document in one round trip.
object
The finding, e.g. INVALID_DOCUMENT, UNKNOWN_ACTION, ACTION_NOT_APPLICABLE.
Index of the statement at fault; -1 for the document as a whole.
The offending action, where one is at fault (ACTION_NOT_APPLICABLE).
Field errors, for codes that carry them: each problem at its field
(see FieldError). Documented on the responses that set it, e.g.
approveNodeJoin’s INVALID_INPUT and JOIN_APPROVAL_REFUSED.
Absent otherwise.
One field’s problem, the stage-2 installer API’s shape.
field is the field’s path, message what is wrong with it.
object
The field’s path, e.g. links[0].interface, disks[1].confirm,
mgmt.address or role; empty for the whole request.
Structured facts about the refusal, for codes that carry them. The
shape is fixed per code and documented on the response that answers
it, e.g. IMAGE_POOL_MISMATCH (see ImagePoolMismatchDetails) and
IMAGE_IN_USE. Absent for codes that carry none.
object
Example
{ "issues": [ { "code": "ACTION_NOT_APPLICABLE", "action": "compute:CreateVpc" } ]}