Introduction

A Cloud Run revision must start successfully, bind to the expected port, and stay healthy long enough for the platform to mark it ready. When that does not happen, traffic cannot shift to the new revision and deployments may appear stuck or fail outright. The root cause is usually in container startup behavior, missing configuration, or dependencies the service assumes are available at boot time.

Symptoms

  • A new Cloud Run deployment completes with errors or leaves the latest revision in a not-ready state.
  • The service keeps serving the older revision because the new revision never becomes active.
  • Logs show container crashes, startup failures, or health check related messages.
  • Requests to the latest revision URL fail while the previous revision still works.
  • Recent configuration or image changes correlate with the readiness failure.

Common Causes

  • The container does not listen on the PORT environment variable expected by Cloud Run.
  • Required environment variables, secrets, or service account permissions are missing.
  • The app exits during startup because a dependency check fails or an exception is thrown.
  • The image entrypoint or command is incorrect for the deployed container.
  • Startup takes too long because the app performs heavy migrations, cache warmups, or remote checks before binding the port.
  • The revision depends on a network path, VPC connector, database, or external API that is unreachable during initialization.

Step-by-Step Fix

  1. Open Cloud Run revision details and read the exact readiness or deployment error shown for the failing revision.
  2. Inspect Cloud Logging for startup output, uncaught exceptions, crash loops, and configuration errors that occur before the service becomes ready.
  3. Confirm the application binds to 0.0.0.0 on the port provided in the PORT environment variable. Hardcoded ports or localhost-only listeners will prevent readiness.
  4. Review environment variables, mounted secrets, and service account permissions. Missing configuration often causes the app to exit before it starts serving.
  5. Check the container image entrypoint and command. Make sure the deployed image starts the intended process in the production runtime, not a development-only command.
  6. Reduce heavy boot-time work. Move migrations, expensive warmup logic, or optional remote dependency checks out of the startup path when possible.
  7. Verify connectivity to required dependencies such as Cloud SQL, Redis, VPC-connected services, or third-party APIs if the app must contact them during initialization.
  8. If the failure started after a new image build, compare the working and failing revisions for changes in base image, startup command, environment, and exposed port behavior.
  9. Deploy a corrected revision and confirm Cloud Run marks it ready before shifting traffic fully.
  10. Finish by testing the live service and reviewing the new revision logs to ensure startup remains stable after deployment.