API
List health ready
Reports the installation health state used by operators and automated probes.
GET
Stable/health/readyReports the installation health state used by operators and automated probes.
Operation IDgetHealthReadyOperation details
Purpose
Reports the installation health state used by operators and automated probes.
When to use it
Use this when an integration needs the current representation before deciding its next action.
When not to use it
Do not use this to infer access to another resource or tenant. Use the matching access check operation and an explicitly selected tenant context.
Contract
Availability
- Product version
- Next Product release
- Licence
- An active Product licence is required except for health, authentication, and licence remediation operations.
- Entitlements
- None
- Service roles
- all
- Deployment
- customer managed installation
- Feature state
- stable
Security
Access
Sign in: No sign in is required.
- Actor
- Unauthenticated caller for this bootstrap, authentication, or health operation
- Permission
- None
- Resource
- Tenant rule
- Installation scoped. A tenant selector does not change this operation's authority boundary.
- Explicit deny
- An applicable explicit deny overrides an allow. Knowing or supplying a resource identifier never grants access.
Request body
This operation does not define a request body.
Responses
| Status | Meaning and correction boundary | Body |
|---|---|---|
200 | The GET operation completed successfully. This action does not expose a separately typed JSON representation. | No response body |
423 | The operation failed with HTTP 423. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
500 | The operation failed with HTTP 500. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
503 | The operation failed with HTTP 503. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
Effects
Behaviour and other effects
- Changes
- Reads current state and does not intentionally change a Product resource.
- Audit events
- None
- Background work
- No background work is inferred. The success response represents completion of the HTTP action.
- External effects
- No external call is inferred from the route name. Operation specific service behaviour remains authoritative.
- Transaction boundary
- The HTTP success or error describes the synchronous boundary. Background operations have their own observable lifecycle and may outlive the request.
Operation
Reliability
- Idempotent
- Yes
- Retry
- A retry is normally safe only with the same resource, body, tenant, and concurrency preconditions. Confirm the first outcome when external effects are possible.
- Concurrency
- Use documented If Match or resource revision fields where exposed. Otherwise read current state before changing it and handle HTTP 409 conflicts.
- Consistency
- The response reflects the synchronous operation boundary. Background and provider backed state can converge later and must be read through its status operation.
- Timeout
- Client timeouts do not cancel completed or already started server work unless the operation explicitly supports cancellation.
- Request ID
- Send or record x request id and retain the returned value for diagnosis.
Errors and corrections
| Status | Code | Cause | Correction | Retryable | Partial work |
|---|---|---|---|---|---|
423 | LICENCE_REMEDIATION_REQUIRED | The installation is restricted and permits only licence remediation actions. | Complete the indicated licence or membership remediation before retrying Product work. | No unchanged retry | No requested mutation is expected before this failure boundary. |
500 | INTERNAL_ERROR | Pūnaha could not complete the operation because of an unexpected internal failure. | Retain x request id and the stable error code, avoid blind retries, and investigate the operation or contact support. Code: INTERNAL_ERROR. | No unchanged retry | No requested mutation is expected before this failure boundary. |
503 | DEPENDENCY_UNAVAILABLE | A required node, database, provider, or service is temporarily unavailable. | Retain x request id, check health and the named dependency, then retry with bounded backoff when safe. | Yes, with the documented safeguards | No requested mutation is expected before this failure boundary. |
Code examples
Use a supported credential and synthetic data. Do not disable TLS checks or retry a request that changes state blindly.
curl --request GET "$PUNAHA_URL/health/ready" \
--header "x-request-id: example-request-001"const response = await fetch(`${PUNAHA_URL}/health/ready`, {
method: "GET",
headers: {
"x-request-id": "example-request-001"
}
});
if (!response.ok) throw new Error(`Pūnaha request failed: ${response.status}`);
const result = response.status === 204 ? undefined : await response.json();using System.Net.Http.Headers;
using System.Text;
using var client = new HttpClient { BaseAddress = new Uri(punahaUrl) };
using var request = new HttpRequestMessage(HttpMethod.Get, "/health/ready");
request.Headers.Add("x-request-id", "example-request-001");
using var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();$headers = @{ "x-request-id" = "example-request-001" }
Invoke-RestMethod -Method GET `
-Uri "$env:PUNAHA_URL/health/ready" `
-Headers $headersRelated APIs
getHealth, read or monitorgetHealthLive, read or monitor
Version history
- Next Product release: Operation documented from the current registered Go route and handler contract.
Was this page helpful?
Your answer helps us improve the documentation.
Do not include personal information, customer information, passwords, or keys.