Diagnose Cloud Run Readiness and Request Failures

Understand the likely causes

• The ingress container must follow the Cloud Run service runtime contract, including the configured PORT and non-loopback binding. Requests can overlap inside an instance, and more instances multiply backing-service pools. Ephemeral local files, unbounded retries, or background work outside its intended lifecycle can introduce further failures. No single scaling flag repairs every layer.

1. Identify the exact revision and failure stage

Record project, region, service, revision/artifact, request path, and timing from existing authorized evidence. Distinguish a startup rejection from a ready service returning an application error. A new traffic split can leave several revisions active, so inspect which one handled the failing request. Preserve the smallest synthetic reproduction without invoking the cloud environment from this guide.

2. Review the container contract

For a request-serving service, verify configured PORT, listening on0.0.0.0, supported image/runtime requirements, startup dependencies, and memory behavior. Jobs have a different completion contract and should not be diagnosed as a service listener. A local-only bind can pass developer tests while failing the platform path. Keep actual configuration snippets non-runnable until adapted and authorized.

3. Check a synthetic downstream connection budget

The complete local program parses invented instance, pool, and reserve assumptions. It reports demand above a synthetic database limit. The arithmetic highlights a question to investigate; it is not a Google quota, a measured workload, or an exact Cloud Run instance ceiling. Real rollout overlap, brief scaling exceedance, other clients, and pool behavior require their documented contracts.

import json

model = json.loads('{"instances":12,"pool":8,"reserve":10,"limit":100}')
demand = model["instances"] * model["pool"] + model["reserve"]
print(f"modeled_demand={demand} synthetic_limit={model["limit"]} fits={demand <= model["limit"]}")

modeled_demand=106 synthetic_limit=100 fits=False

4. Separate ingress, caller identity, and dependency access

An allowed ingress path does not grant invocation authority, and a valid caller token does not grant the runtime account database access. Trace each principal, token audience, VPC/client path, and target permission. Diagnose authentication errors separately from startup or saturation. Do not make a service public or grant broad roles just to remove the visible symptom.

5. Propose a bounded application and scaling correction

Review handler concurrency safety, per-instance pool limits, queueing, timeouts, retry amplification, and idempotency. Externalize required durable state and define graceful shutdown. Reverting traffic can be part of an approved rollback, but schema changes may need their own compatibility plan. The guide runs no container, load test, deployment, traffic change, or cloud command.

Keep it from recurring

• Keep immutable artifact identity, explicit runtime/identity settings, bounded pools and retries, and application SLIs. Review scaling together with dependency capacity and instance-lifetime state. Preserve readiness and failure-stage evidence without logging secrets or full sensitive requests.