Service readiness

Deployment checks must measure the dependency the product needs, not just whether its process is alive.

Liveness and readiness

GET /health reports process liveness. GET /readyz exercises required dependencies, such as credential redemption, a database round trip or a broker handshake. A failed dependency produces 503 and a diagnostic identifying the failed operation without exposing credentials.

Deployment checks, uptime monitors and release qualification use readiness. A successful liveness response does not establish that the product works. Brama's readiness contract is described in its canonical documentation.

Authorization is not capacity

A refused credential, expired capability, mismatched authorization identity or revoked grant requires the corresponding authorization state to change. Gateway dependency failures of this kind report 503 authorization_error with retryable: false and the action needed to restore access. They must not be reported as 429 capacity_error or as retryable capacity shortages.

Retry only when repetition can help

A supervisor, dispatcher or client must distinguish a temporary failure from a state the same operation cannot repair. Missing configuration, a trashed credential item or an unregistered workload key does not become valid because the caller repeats its request or restarts its process.

When repetition cannot change the outcome, stop the retry path, retain the actual operation and error, and name the state that must change. Skarbiec distinguishes a trashed item with 410 Gone and an incompatible legacy envelope with 409; these are not infrastructure-capacity failures. See the Skarbiec contract for recovery through its supported interface.

Evidence and publication

Readiness observations belong in the product's retained run records. Public documentation describes the contract and diagnostic interpretation; it does not embed operator identities, deployment logs, private hosts or incident timelines.