Choose Cloud Run health checks by the action a failed check should trigger. Startup asks whether the container can begin serving, liveness asks whether restarting this instance can help, and readiness asks whether it should receive new traffic. Match the available controls to the Cloud Run resource and current deployment configuration. A response body saying degraded does not change the HTTP status a probe evaluates.
Begin with the platform action
For each probe, write the intended action before writing the endpoint. A startup failure can stop an instance from becoming available. A liveness failure can restart it. A readiness failure can remove it from new traffic until recovery under the supported service contract. Using one dependency-heavy endpoint for every purpose can restart many otherwise healthy processes during a shared database outage.
Current Cloud Run service documentation describes startup, liveness and readiness probes and their behavior. Check the resource type, supported probe protocol and current launch-stage conditions in the deployment you use. Do not transplant a Kubernetes configuration or a worker-pool assumption into a Cloud Run service without verifying its supported fields.
Cloud Run: container health-check types and actions
A synthetic database-outage decision
Imagine a responsive API process whose database is temporarily unavailable. The process can still answer a local health request, but a core product read cannot finish. If restarting cannot repair the shared dependency, a liveness failure may produce needless churn. Readiness or external monitoring may be the appropriate place to express that dependency state, subject to the service's supported controls and your availability policy.
| Signal | Question | Possible chosen policy |
|---|---|---|
| Startup | Required initialization completed? | Bound initial admission |
| Liveness | Can process make progress? | Avoid dependency-only restart loops |
| Readiness | Can intended work be accepted? | Withhold traffic if appropriate |
| External task | Does user workflow succeed? | Alert on product degradation |
These are proposed decisions, not observations of a deployed service. Some products can serve useful cached or non-database paths during an outage and should define readiness more narrowly. Others cannot satisfy any accepted task without the dependency. Make that product decision explicit rather than equating one dependency check with universal process health.
Return the status the probe actually reads
For an HTTP probe, inspect the platform's documented success status range and the actual wire response. An endpoint returning 200 with status='unavailable' in JSON can be useful for an external diagnostic client, but a status-based probe may still count it as success. Conversely, a 503 selected for readiness should not automatically be reused for liveness. Separate public diagnostics from operational probe semantics where that makes the contract clearer.
Proposed probe worksheet
startup: required initialization completed?
liveness: can this process make progress, and would restart help?
readiness: can this instance accept the intended new work?
external monitor: can a synthetic user task complete end to end?Keep probe work cheap and bounded. A health endpoint that opens expensive queries on every check can amplify load during degradation. Choose timeouts and thresholds from the initialization and failure modes you actually observe. Avoid publishing database exception text, topology or credentials in a public health payload. Operators can correlate a safe status category with protected diagnostics.
Test degradation and recovery together
Use an isolated service with a controllable fake dependency or disposable database. Test slow startup, a process-level deadlock simulation, dependency refusal and dependency recovery. Observe traffic admission, restart count and the end-to-end task outcome separately. A passing liveness probe does not prove the product task works, while a failed external task does not prove restarting this instance is helpful.
No Cloud Run probe experiment was executed for this article. The source review establishes a health endpoint as implementation context, not a claim about configured probes or live platform actions. Before release, inspect the deployed revision's probe configuration, capture actual status responses and verify one degraded-to-recovered transition. That evidence makes the operating assumption reviewable and prevents a descriptive JSON field from becoming an unintended availability policy.
Cloud Run cold start measurement
Observability for small teams: start with the failed customer task
Bring one API or data workflow and a sanitized failure example for a bounded implementation assessment.
How should Cloud Run startup, liveness and readiness checks differ?
Tie each check to its platform action: startup admission, instance restart or traffic readiness, then verify actual HTTP status and deployed probe configuration.
Does a JSON degraded field fail an HTTP probe?
Not by itself. Verify the HTTP status and the platform’s documented probe evaluation.
Should a shared database outage fail liveness?
Only if restarting that instance is the intended useful recovery action; evaluate readiness and external monitoring separately.