System Operations
resource: system — unauthenticated pre-flight checks, 2 operations
authMethod and
credentialID are omitted entirely — only vaultAddress is needed. That's
intentional: these are pre-flight checks you'd want to run before trusting any authenticated
call to succeed, and Vault itself answers both endpoints without a token.
health
Vault's own /v1/sys/health endpoint encodes cluster role in its HTTP status code
rather than in a success/failure body. This node normalizes every documented code into a
successful result carrying the decoded state — only a genuine network failure (no
response at all) produces an error.
| Vault status code | Meaning |
|---|---|
| 200 | Initialized, unsealed, active node |
| 429 | Unsealed, standby node |
| 472 | Disaster recovery secondary |
| 473 | Performance standby |
| 474 | Standby node unreachable from the active node |
| 501 | Not initialized |
| 503 | Sealed |
| 530 | Removed from cluster (Vault Enterprise) |
The request is sent with standbyok=true&perfstandbyok=true — because the point of
this operation is "is any node in this cluster reachable and unsealed," not "is this specific address
the active leader."
Example response:
{
"initialized": true,
"sealed": false,
"standby": false,
"version": "1.16.2",
"clusterName": "vault-cluster-prod",
"statusCode": 200
}sealStatus
Answers even when Vault is sealed — useful as a pre-flight check before any authenticated operation,
which would otherwise fail outright with HASHICORP_SEALED.
Example response:
{ "sealed": false, "t": 3, "n": 5, "progress": 0 }| Field | Meaning |
|---|---|
sealed | Whether Vault is currently sealed. |
t | Shamir key-share threshold — number of key shares required to unseal. |
n | Total number of key shares that exist. |
progress | How many valid unseal keys have been supplied so far toward t. |
t/n naming: kept exactly as Vault itself documents them
(Shamir secret-sharing notation) rather than renamed to something friendlier, so this node's output
matches Vault's own documentation and API responses field-for-field.
system/sealStatus (and optionally
system/health) as the first step of any workflow that follows with authenticated
HashiCorp operations, and branch to an error/notification path if sealed is true — this
avoids every subsequent step failing individually with HASHICORP_SEALED.