---
cuppy_hub: gcp
cuppy_path: guides/observability/find-the-failing-call-in-cloud-logging.md
cuppy_section: docs
cuppy_doc: 9RNY-3QGH
cuppy_doc_uuid: 2edc318a-2903-4cc7-b92d-bed4e2b4e82b
cuppy_permalink: https://cuppy.io/gcp/d/9RNY-3QGH
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/guides/observability/find-the-failing-call-in-cloud-logging
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: e71bad2e36c0d52449076d67b1ee212dd04612bac054da746e467d9ad80cf15d
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Find the failing call

## Step 1 — narrow by resource and severity, in that order

Query in the **Logging query language**, starting from the two filters that cut the most:

```
resource.type="<the service>"
severity>=ERROR
```

Resource first, because severity alone across a busy project returns everything that was ever unhappy.

## Step 2 — narrow to the verbatim string

Take the error text **exactly as the caller received it** and search for it. Every error catalogue in this hub
is indexed that way, and so is a log query. Do not paraphrase and do not trim an error code
(`reference/compute/errors.md`, `reference/storage/errors.md`,
`reference/data/errors.md`, `reference/identity/errors.md`).

If nothing matches, ask whether the log is there at all before concluding the error did not happen:
`reference/observability/errors.md` §4 lists the three reasons it might be missing.

## Step 3 — read the principal out of the error, not out of your assumptions

A Google Cloud permission error carries an **error ID** whose context is "the principal, resource,
permission". In three common cases the principal is **not** the one you expect:

- **Config Connector** reconciles as its own service account, "not the identity of the human user or service
  account that submitted the manifest";
- a **Cloud Run deploy** involves you, the runtime service account **and** the service agent;
- any **CI pipeline** acts as its own identity.

Diagnosing with the wrong principal answers the wrong question
(`guides/identity/fix-permission-denied.md` step 2).

## Step 4 — cross-check the trace, knowing it may not exist

If the request was traced, the **spans** show where the latency or the failure sat. If there is no trace,
establish whether **sampling** means it was never recorded before you go looking for broken instrumentation —
those two look identical (`reference/observability/cloud-trace.md` §4).

## Step 5 — turn the query into a log-based metric

A query you had to reconstruct is a query you will have to reconstruct again. Make the narrowed query a
**log-based metric**; it then behaves like any other metric — chartable, alertable, usable in an SLO.

## Step 6 — alert on it, and test the channel

1. an **alerting policy** over the log-based metric;
2. a **notification channel** attached;
3. **a test delivery through that channel.**

Step 3 is the one that gets skipped, and a policy with a correct condition and an unverified channel fires
**silently**. That is worse than no alert, because the dashboard looks healthy
(`reference/observability/errors.md` §3).

Also confirm the resource's project is inside the **metrics scope**, or the policy watches a series that does
not reach it.

## For a migration

Do this **before** the migration, on the source platform, for the five errors that matter most. You then have
a baseline — the same five failures, counted — against which the target can be compared, and you discover the
observability gaps while there is still something to compare against. Alerting policies are **re-created** on
the far side rather than migrated, so the count of them is a direct effort estimate
(`guides/parity/observability.md`).


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->