Hi,
I am experiencing what appears to be a project-specific Cloud Run runtime/provisioning issue.
Important: this is not only reproducible with my application container. Google’s official Cloud Run hello image also fails in the affected project, while the exact same image succeeds in a newly created project in the same region.
Therefore, this does not appear to be a localhost / 0.0.0.0 / PORT binding issue in my application.
Summary
I originally encountered the issue while deploying a new revision of an existing Cloud Run application.
Cloud Run reported:
“The user-provided container failed to start and listen on the port defined provided by the PORT=8080 environment variable within the allocated timeout.”
At first I suspected my Node.js application, Dockerfile, dependencies, or startup configuration.
However, after isolating the problem, I can reproduce the same failure with Google’s official Cloud Run hello image.
Reproduction tests
The following all fail in the affected project:
-
My current application image.
-
A previously known-good production image.
-
A minimal Node 20 HTTP server using only the built-in
httpmodule. -
Google’s official Cloud Run hello image:
us-docker.pkg.dev/cloudrun/container/hello
I also tested:
- Gen1 execution environment: FAIL
- Gen2 execution environment: FAIL
- asia-east1: FAIL
- asia-northeast1: FAIL
The behavior is consistent: a newly created Cloud Run instance never passes the TCP startup probe on port 8080.
Control experiment
I created a fresh GCP project specifically as a control test.
I deployed the same Google-maintained Cloud Run hello image to asia-east1.
Results:
Affected project
- Google official hello image
- asia-east1
= FAIL
Fresh control project
- same Google official hello image
- asia-east1
= SUCCESS
The deployment in the fresh project became healthy normally.
This is the strongest reason I suspect the problem is specific to the affected GCP project rather than the application, container image, PORT configuration, or region.
Detailed failed official hello test
Failed revision:
cloudrun-official-gen2-test-00001-vq7
Operation ID:
20a99f3f-bf8c-47ca-9d9b-261939dccf88
Failure window:
2026-09-10T06:49:40Z to 2026-09-10T06:53:44Z
The failed revision used:
- Google’s official Cloud Run hello image
- Gen2 execution environment
- 1 CPU
- 512 MiB memory
- containerPort: 8080
- TCP startup probe on port 8080
- no custom command
- no custom args
- no VPC connector
- no custom environment variables
Cloud Run reports:
- ContainerReady=True
- “Container image import completed.”
- ResourcesAvailable=True
- “Provisioning imported containers completed in 1.31s.”
- Cloud Run then waits the full 4-minute startup probe period.
- ContainerHealthy=False
- HealthCheckContainerError
There is no application stdout/stderr from the official hello container during the failed startup.
The only final error is the generic message saying that the container failed to start and listen on PORT=8080.
Checks already performed
I have also checked the following:
- Project lifecycle state is ACTIVE.
- Billing is enabled.
- run.googleapis.com is enabled.
- Cloud Run service agent has roles/run.serviceAgent.
- Default Compute service account exists and has project permissions.
- Audit logs confirm iam.serviceAccounts.actAs was granted during revision creation.
- No project-level Org Policies were found.
- No project-attached IAM Deny policies were found.
- No VPC connector is configured on the official hello test.
- No relevant non-default Cloud Run quota overrides were found for asia-east1 or asia-northeast1.
- No IAM denial was found in the failure window.
- No Service Usage denial was found.
- No quota exhaustion was found.
- No policy denial was found.
- No resource exhaustion error was found.
- Personalized Service Health currently reports no active incident.
I also compared enabled APIs between the affected project and the healthy control project.
All services enabled in the healthy control project that are relevant to this test are also enabled in the affected project.
What appears to be ruled out
Based on these tests, the following appear to be reasonably ruled out:
- Application code
- Node.js / npm startup
- Dockerfile
- Custom container image
- localhost / 0.0.0.0 binding in my application
- PORT configuration in my application
- Custom command / args
- Gen1 vs Gen2
- A single-region Cloud Run issue
- Billing being disabled
- Cloud Run API being disabled
- Basic Cloud Run service-agent IAM binding
- Deploy-time service account actAs denial
- Project-level Org Policy
- Project-attached IAM Deny
- Obvious quota exhaustion
Most importantly, Google’s own Cloud Run hello image reproduces the failure in the affected project, while the same image works in a fresh project.
Questions
Is there any project-specific Cloud Run provisioning, service identity, runtime, sandbox, or internal data-plane state that could cause newly created Cloud Run instances in one project to fail before the container becomes reachable by the TCP startup probe?
Is there anything else available to a customer through gcloud, Cloud Logging, Cloud Audit Logs, or another diagnostic API that I can inspect?
If a Googler is able to escalate or investigate this internally, could you please check the Cloud Run backend/runtime telemetry associated with:
Revision:
cloudrun-official-gen2-test-00001-vq7
Operation ID:
20a99f3f-bf8c-47ca-9d9b-261939dccf88
Failure time:
2026-09-10T06:49:40Z – 2026-09-10T06:53:44Z
The main question I am trying to answer is:
Why can Cloud Run successfully import and provision Google’s own hello container in this project, but the instance never becomes reachable on TCP port 8080, while the exact same Google-maintained image succeeds in a fresh GCP project in the same region?
If possible, please compare the affected project’s internal Cloud Run provisioning/service identity/runtime state with the healthy control project.
Thank you.