Verify access

Applying a grant and Bobbin 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, Bobbin 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 Bobbin (@bobby) exist, pointing at this tenant’s own topic?

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

A project that verified once 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.

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.
Monitored	Verified: all four roles and the channel are confirmed. Alerts reach Bobby.
Cannot see it	The check ran and found roles or the channel missing — the pill names which.
Could not check	Bobbin’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.

“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 Configuration 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 Cloud Audit Logs as your action, and every subsequent read by Bobbin’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 — 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 the domain-restricted sharing policy, which fails silently in exactly this shape.
• 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@getbobbin.dev, with the project id and what the pill says.