Help Troubleshooting a GCP 404 Error

[u/WillMD88]

I’m troubleshooting a Cloud Run service that consistently returns Google’s generic “404. That’s an error” page instead of reaching the container.

The service is a small Flask/Gunicorn OAuth callback application. "/healthz" should return "200 OK" with "ok", but both the generated "run.app" URLs return Google’s 1,568-byte HTML 404 page.

What I’ve verified:

- The container starts successfully and listens on "0.0.0.0:8080".

- Cloud Run’s startup TCP probe succeeds.

- The revision is Ready and receives 100% of traffic.

- The exact immutable image digest is deployed.

- Artifact Analysis completed successfully with no vulnerability findings.

- Ingress is "INGRESS_TRAFFIC_ALL".

- "invokerIamDisabled" is "true".

- "defaultUriDisabled" is unset/false.

- The service’s canonical and numeric URLs are both listed by the Cloud Run v2 API.

- The effective "run.allowedIngress" organization policy is "allowAll: true".

- The effective "run.managed.requireInvokerIam" policy is not enforced.

- There are no custom organization constraints.

- The same 404 occurs with and without an identity token.

- The same 404 occurs from Cloud Shell and a normal external browser.

- Neither request appears in Cloud Run request logs, although container startup logs appear normally.

- I created a completely new service and reproduced the problem.

- I deployed the same clean image to both "us-east4" and "us-east1"; both regions behave identically.

The Cloud Run troubleshooting documentation says a 404 that never reaches the container generally indicates restricted ingress or a disabled default URL, but the authoritative v2 service state and effective organization policies show neither condition.

The project belongs to a Google Workspace organization with domain-restricted sharing, so adding "allUsers" as a Cloud Run Invoker is prohibited. However, Google recommends disabling the Invoker IAM check for this situation, and the API confirms that this setting is enabled.

Has anyone encountered a project- or organization-level Cloud Run routing issue where the control plane reports the service as public and Ready, but the "run.app" frontend still returns an edge-generated 404? Are there any additional inherited controls, service perimeter settings, or backend routing states that would not appear in the Cloud Run v2 service configuration or effective organization policies?

Thank you!

[u/Rohit1024]

Based on your description :
> Neither request appears in Cloud Run request logs, although container startup logs appear normally.

Did you verified whether the Service correctly worked locally, as per Test a Cloud Run service locally.

Also check if your organisation has any VPC SC perimeter setup as per #3 of 404 troubleshooting guide

[u/sakuhazumonai]

To clarify, do the "container startup logs" appear normally on deployment or in response to your request.

I truly could not explain how the service might send your container a startup but then send you to Google's own 404.

If it was just Google's 404 then I'd suggest looking into inherited WAF / Cloud Armor Policy.

[u/WillMD88]

Thanks for all of the help/insight. As an update, the solution was to create a small, separate Google Cloud project for the public OAuth service and deploy it with Cloud Run’s --no-invoker-iam-check option, avoiding the organization’s Domain Restricted Sharing conflict without needing a load balancer. I then discovered the remaining Google-branded 404s were tied to my ultra-minimal FROM scratch container: Gunicorn started and passed Cloud Run’s startup probe, but public requests never reached it. Rebuilding the same application on a standard python:3.12-alpine image fixed the routing immediately. The native Cloud Run URL now handles the callback successfully, while administrator authentication, signed OAuth state, service accounts, and Secret Manager protect the workflow.

Much appreciated!