Kubernetes / Cluster Operations, Access & Incident Response
Check API readiness without treating it as full cluster health
A successful API request can coexist with failing storage, networking or controllers. Read the documented readiness endpoint as one bounded signal.
Environment and inputs: Kubernetes · kubectl with supported client/server versions and delegated RBAC. Examples use namespace app unless noted. Check context, namespace, APIs and provider support first.
Start with this check
Confirm the environment and replace sample objects, namespaces, images, paths and hosts with approved targets. Share only relevant, sanitized output. Follow the workload owner’s process for changes.
kubectl get --raw='/readyz'
Read the result
With authorized API access, this queries the readiness endpoint. Access can be restricted and one healthy response does not certify every workload or control-plane replica.
Resolve and verify
Correlate failures with provider status and control-plane diagnostics, then investigate the specific dependency through the cluster owner's runbook.
Before changing production
Do not expose health endpoints publicly or change API authentication merely to make a probe succeed.