Verify access

Applying a grant and Nodrik actually being able to read your project are two different claims. An org policy, a role typo, or a channel pointing at the wrong topic can all make a grant look complete without working — so the console checks the second claim directly, rather than assuming it follows from the first.

How the check works

Once an hour, Nodrik impersonates your own tenant service account — the same identity an investigation uses — and asks your project two questions:

• Does this identity hold the permission each of the four roles carries? (testIamPermissions, one permission per role, chosen so no other role grants it — a missing permission points at exactly one role.)
• Does a pubsub notification channel named Nodrik (@nodrik) exist, pointing at this tenant’s own topic?

Checking as your own granted identity, rather than as Nodrik’s own identity, answers the right question: not “can we see the project” but “can the principal you bound roles to see it”.

Once those two answers are yes, the same check does the one thing that is ours to do rather than yours: it reads your project’s number (using the identity you already granted — nothing further is asked of you) and grants your project’s Cloud Monitoring agent pubsub.publisher on your tenant topic, so the channel it created can actually deliver to it. This happens automatically, on every check, until it has landed — which is what Confirming alerts below is for.

A project where both halves are confirmed is left alone until something disturbs it — re-proving a working grant every hour costs a check for no new information, and a grant that is later revoked surfaces the moment an investigation actually fails. A project stuck on Confirming alerts is the exception, and is retried every hour until the binding lands: that half is ours, so leaving it to you to notice a pill would be the wrong way round.

What each pill means

Pill	Meaning
Awaiting access	Never checked. Nobody has run a grant for this project yet, or the first check has not run.
Checking	A check this browser started is in flight.
Confirming alerts	Your four roles and the channel are confirmed. Nodrik is still confirming the one remaining step on our side — granting your project’s Cloud Monitoring agent publish rights on your topic — which it does automatically and usually clears within a few minutes of your grant landing.
Monitored	Fully verified: your four roles, the channel, and Nodrik’s own topic-side grant are all confirmed. Alerts reach it once a policy notifies the channel.
Cannot see it	The check ran and found roles or the channel missing — the pill names which.
Could not check	Nodrik’s own call failed — a Google outage, a disabled API on our side. This is never read as “ungranted”; it means exactly what it says, and the last known state is kept until the next check succeeds.

Verified is not the same as receiving

Monitored means Nodrik can read the project. It does not mean anything has actually been sent. The channel is an address; an alerting policy has to be told to notify it, which is a step in your own project that this check cannot see. If a project has been Monitored for days in silence, that is where to look — send your alerts to Nodrik.

“Could not check” never becomes “cannot see it.” Reporting a correctly-granted project as ungranted because our own call timed out would be a worse failure than the one this check exists to prevent — so an inconclusive check stays inconclusive rather than guessing.

Check again

Every project row in the console’s Settings page carries a Check again action, alongside when it was last checked. Use it right after running a grant, rather than waiting for the next hourly sweep — the check itself takes a few seconds.

Confirm it yourself

Because the grant is applied under your own authority — whichever of the three paths you used — it appears in your Admin Activity audit log as your action. That log is always on, so the grant itself is provable the moment you apply it.

The reads Nodrik’s service account makes afterwards are a different log. They are Data Access audit log entries, and Google leaves Data Access logging off by default for every service except BigQuery — so until you turn it on, the query below returns the grant and nothing else, not Nodrik’s reads. Turn it on once: Cloud Console → IAM & Admin → Audit Logs, select Cloud Logging, Cloud Monitoring, Cloud Run Admin and Error Reporting (plus any configuration-role service you opted into), enable Admin Read and Data Read for each, and save.

From then on, every subsequent read by Nodrik’s service account is attributable to that identity:

gcloud logging read \
  'protoPayload.authenticationInfo.principalEmail="YOUR_TENANT_SA"' \
  --project YOUR_PROJECT --freshness 30d

You do not have to take the console’s pill at face value — once Data Access logging is on, this query shows exactly what has been read, and nothing else.

If a project still reads “cannot see it”

The pill names which roles or the channel are missing, which is usually enough on its own. If you ran the grant script and it reported success but the check still disagrees:

• Re-run the same script or Terraform command — every path is idempotent, so re-applying an existing binding is a no-op and will not create duplicates.
• Check for domain-restricted sharing, which fails in exactly this shape: the grant is refused wholesale, so the check reports the project as not connected and it looks identical to never having run the grant at all. Neither we nor the console can tell those apart — reading your IAM policy needs a permission the grant was refused for. Domain-restricted sharing is the page to send your organisation admin.
• Confirm the notification channel points at your topic — a channel created against the wrong topic id passes the “does a channel exist” question and fails the “does it point at the right place” one.

Still stuck: support@nodrik.dev, with the project id and what the pill says.