Project IDs: (PII Removed by Staff)
Region: us-central1
Issue: Multiple Cloud Run services, deployed cleanly via gcloud run deploy --source, are unreachable from the public internet at their default *.run.app URL. Every request returns Google’s generic branded 404 (“That’s an error… was not found on this server”) rather than anything from the container, and this occurs even for a trivial /healthz endpoint that returns 200 locally.
Cloud Run request logs (run.googleapis.com/requests) return zero entries despite repeated requests — confirms requests never reach the serving layer at all
curl -v shows a valid TLS handshake with a correctly-matched Google-issued cert (CN=*.a.run.app, SAN includes the exact hostname), but the 404 response carries no Cloud Run-specific headers (no trace/served-by markers) — consistent with Google’s edge (GFE) never routing the request to any backend
Isolation testing performed (all show the identical failure):
A brand-new project (not shown above, already deleted) — same failure
An established project several days old, confirmed working billing (PII Removed by Staff) — same failure
A project with NO organization attached (dhammasoftweb) — same failure, ruling out an org-level cause
Two different Google accounts as the deploying identity — same failure, ruling out an account-level cause
Tested from three independent network paths: local machine (PowerShell/curl), a standard browser, and Google Cloud Shell itself — identical result in all three, ruling out any client-side/network cause
Given the issue reproduces identically across project, organization, deploying-account, and network-path variations, this appears to be a platform-level routing/registration problem rather than anything user-configurable. Would appreciate help investigating Cloud Run hostname provisioning / Google Frontend routing-table registration for these project numbers.
Issue: Cloud Run services deployed cleanly via `gcloud run deploy --source .` are unreachable at their default *.run.app URL. Every request — including a trivial GET /healthz that returns 200 locally and via a local Docker/Node boot test — returns Google’s generic branded 404 page (“That’s an error… was not found on this server”) instead of any response from the container.
What’s confirmed working: -
`gcloud run services describe` shows status.conditions: Ready=True, ConfigurationsReady=True, RoutesReady=True
Correct image, correct containerPort (8080), correct env vars
IAM confirmed via `gcloud run services get-iam-policy`: bindings:
Container logs (via `gcloud logging read`) confirm clean startup: “Default STARTUP TCP probe succeeded after 1 attempt … on port 8080” " listening on port 8080"
No log entries for the actual failing requests at all — zero request logs, matching resource.type=“cloud_run_revision”
Reproduction steps tried, all producing the identical Google-branded 404:
curl against the public *.run.app URL (both the “PROJECT_NUMBER.region.run.app” and the “HASH-region.a.run.app” format — gcloud run services describe returns the latter as status.url)
`gcloud run services proxy SERVICE --region REGION --port=8081` (authenticated tunnel via the Cloud Run Admin API, bypassing public DNS/edge entirely) — curl against localhost through this tunnel gives the same 404
Deployed a second service to a second region (us-central1) as a control — identical failure, ruling out a region-specific issue
Full `gcloud auth login --update-adc`
Full “Reset Cloud Shell (clean VM state)” — completely fresh Cloud Shell VM (confirmed via new cloudshell-config-name), re-authenticated from scratch — identical failure persisted
One possibly-related but likely-unrelated observation: every gcloud command in this project (including successful ones — project creation, billing link, IAM changes) surfaced this warning throughout most of the session: “Regional Access Boundary HTTP request failed after retries: response_data= {‘error’: {‘code’: 404, ‘message’: ‘Not found; Gaia id not found for email [redacted]’, ‘status’: ‘NOT_FOUND’}}, retryable_error=False” This warning did clear after the Cloud Shell reset, but the core 404 routing issue was unaffected either way — so I don’t believe it’s the root cause, but flagging it in case it’s a useful clue for someone investigating.
Support routing notes: I don’t have permission to file a technical support case for this project (Console: “You don’t have permission to file tech-related support cases for projects/xxx”), and Billing Support explicitly declined it as “a technical identity or authentication issue… unrelated to Google Cloud Billing.” Posting here since self-service support routing was a dead end for this specific error.
Willing to provide any additional diagnostic output if it helps triage this.
+1 — identical signature, started ~2026-07-19 14:00 UTC, project in europe-west1 AND
europe-west4 (so not region-specific for us either). Deployed via --image (prebuilt
Artifact Registry image), so this spans both --source and --image paths.
Same as reported: Ready/RoutesReady/ConfigurationsReady=True, allUsers→run.invoker,
ingress=all, container boots and passes startup probe on 8080, zero request logs, generic
GFE 404 on both the legacy and hash run.app forms, valid TLS.
Two things that may help localize it:
It’s per-request, not per-service. On the SAME hostname in the SAME minute, HTTP/1.1
(curl) gets the GFE 404 while HTTP/3 requests DO reach the container — confirmed by
request-log entries with trace IDs appearing for the h3 requests while h1.1 clients
get the robot page. Looks like the TCP/h1 serving path is missing routes the QUIC/h3
path has.
Single-hostname A/B: on one service I swapped only the container command (trivial node -e HTTP server ↔ the real app image CMD) via gcloud run services update.
The trivial server was reachable over TCP; swapping to the real app CMD made the SAME
hostname return the GFE 404 immediately. An identical service running gcr.io/cloudrun/
hello, or a bare node -e server in the same image, is reachable over TCP within
seconds — so it correlates with the running process, not config/IAM/ingress.
Established services in the project (created weeks ago) are completely unaffected. Only
newly-created services exhibit it.
Update — [21 July 2026]: still reproducing, no change.
Follow-up from my end — still reproducing as of [21 Jul 2026, ~16:30 UTC], no change and no config edits since my previous post.
New data point: custom domain mapping shows the identical failure. Mapped a verified custom domain to an affected (newly-created) service — DNS/cert provisioned fine, mapping reports ready, but requests hit the same generic GFE 404 with zero request logs, same as the run.app forms. So this isn’t specific to the *.run.app frontend: the custom-domain ingress path (separate GFE/cert termination) reaches the same broken serving path. Rules out the run.app hostname/GFE mapping as the sole culprit — the defect is downstream, on the request→container route for the running process.
Recap of what still holds:
per-request not per-service (h3/QUIC reaches the container and logs trace IDs; h1.1/TCP gets the GFE 404 on the same hostname in the same minute); reachability correlates with the running process, not config/IAM/ingress (trivial node -e server on the same hostname is reachable, real app CMD → immediate 404); only newly-created services affected, established ones untouched; now confirmed across run.app (legacy + hash) and custom domains.
Could a Googler / moderator confirm whether this is a known issue and whether it’s been escalated to the Cloud Run serving team? This is blocking all new-service deploys. Happy to share project numbers, revision names, exact timestamps, and the h1.1-vs-h3 trace IDs privately for triage.