Hi,
I’m seeing a Cloud Run routing failure in a separate Google Cloud project and would appreciate any guidance from Googlers or other users who may have seen the same behavior.
Environment:
- Region: asia-southeast1
- Service: mastermind-intake
- Cloud Run service is private/authenticated
- Revision Ready = true
- RoutesReady = true
- 100% traffic to the active revision
- Ingress = all
- Default run.app URL enabled
Observed behavior:
Authenticated requests to /healthz return a generic Google edge 404 before reaching the Cloud Run revision.
No Cloud Run request log is generated.
The container itself is healthy:
- Starts successfully
- Listens on port 8080
- Startup probe passes
Troubleshooting already completed:
- IAM verified
- token audience verified
- DNS verified
- VPC Service Controls ruled out
- organization policies ruled out
- container health verified
- traffic routing verified
- both documented run.app hostnames reproduce the same 404
- all resolved Singapore frontend IPv4 addresses reproduce the same 404
- service was deleted and recreated with the same configuration; issue persisted
A Cloud Run Job in the same project and region works normally.
I also found public Issue Tracker case #564071943 describing the same edge-404/no-request-log symptom in a different project and different regions. That issue was later closed with guidance to use a support ticket because internal backend configuration cannot be inspected through the public Issue Tracker.
My current Basic Support plan does not allow a technical support case.
Questions:
- Has anyone seen this same Cloud Run edge 404 behavior recently?
- Is there any additional safe customer-side diagnostic that does not involve weakening authentication, broadening IAM, or recreating services again?
- Is there any free escalation path for a suspected provider-side routing issue when Basic Support does not include technical case creation?
I am leaving the service unchanged while this is investigated.
This is a very thorough troubleshooting report. Since the service is healthy, traffic is routed correctly, authentication has been verified, and there are no Cloud Run request logs before the 404, the edge/routing layer seems like an important area to investigate.
The fact that recreating the service produced the same behavior and that a Cloud Run Job in the same project and region works is also useful evidence. Hopefully someone from Google Cloud can confirm whether there is a known regional routing issue or provide a support/escalation path for Basic Support users.
I can independently reproduce the same provider-edge 404 today in a separate standalone project.
Additional evidence from my environment:
- Cloud Run service reports Ready=True and RoutesReady=True, with 100% traffic to the latest revision.
- Ingress is all, allUsers has roles/run.invoker, and the default run.app URL is explicitly enabled.
- Both the hashed and deterministic run.app hostnames return Google’s generic HTML 404 for /healthz.
- No Cloud Run request log is created; the request never reaches the container.
- The container starts successfully, Uvicorn listens on 0.0.0.0:8080, and the startup probe passes.
- Reapplying ingress did not help.
- A newly created service using the same immutable image showed the same result.
- I reproduced it in both us-west1 and us-central1.
- I also ran curl from Google Cloud Build, ruling out my local DNS/network; it received the same Google edge 404.
- There is no organization/folder parent, no effective organization policy, and no VPC Service Controls HttpIngress denial log.
- A Firebase Hosting-to-Cloud-Run rewrite also reached the same missing route.
This appears project/control-plane related rather than an application, IAM, region, or client-network issue. Basic Support does not allow me to open a technical case. Is there a way for a Googler to correlate this with the other recent edge-404 reports or escalate it internally?