You can ask for this instead of navigating to it. Ask Command Center "is Google Cloud connected?" and it reports which GCP project each connection reads from, which service account it acts as, whether it is working right now per capability (logs, error reporting, BigQuery), and whether the agents are allowed to use it. A connection with no allowed datasets is connected and can query nothing — that is usually the answer to "it sees nothing". Pasting the key stays here: a credential must never travel through a chat transcript.
What it is
When a bug report comes in, the question is usually "what did production actually do?" — and the answer is in your logs, not in the ticket. This connector lets FixControl read a bounded slice of your Google Cloud telemetry and put it in front of the agent that reasons about the bug.
It reads. It cannot write. There is no write path in it at all.
Open it at Settings → Channels → Data sources → Google Cloud (read-only). You need to be an admin of your FixControl organization.
What it reads
| Service | What FixControl asks for | Where it shows up |
|---|---|---|
| Error Reporting | The top error groups in a period: count, affected users, service, last seen, title | On the QA note of a BUG patch |
| Cloud Logging | Recent log entries, newest first, filtered by severity and by your log allowlist | On the QA note of a BUG patch |
| BigQuery | A single read-only SELECT, plus dataset and table introspection | Not used yet. The connection test lists datasets to prove the credential works, and nothing else reads BigQuery — no screen, no agent, no QA note |
Be clear about that last row: the BigQuery half is built, guarded, cost-fenced and exercised by the connection test, but nothing in the product uses it. Configure the dataset allowlist if you want the capability proven green; do not plan a workflow around it until a surface asks for it.
Read-only, four times over
Read-only is not a promise here; it is four independent mechanisms, and each one alone would be enough:
- The token cannot write. FixControl mints Google access tokens with read-only scopes, and it mints them per service — so a request to Cloud Logging never carries a credential that could reach BigQuery. No write scope appears anywhere in the connector.
- The endpoints cannot write. Only list, get and query endpoints are called.
- The query cannot write. A BigQuery statement must be a single
SELECT(orWITH … SELECT).INSERT,UPDATE,DELETE,MERGE,TRUNCATE,CREATE,ALTER,DROP,GRANT,REVOKE,EXPORT,LOADand the transaction verbs are refused outright, and every table named must be inside your dataset allowlist. - The spend cannot run away. A query is dry-run first and refused if it would scan more than your ceiling, and the real run carries that ceiling as a hard limit.
Setting it up
You paste a service-account JSON key. There is no OAuth consent screen for this connector; it is a machine identity you control, and you can revoke it in Google Cloud without touching FixControl.
Grant that service account the least it needs:
roles/logging.viewerroles/errorreporting.viewer- for BigQuery:
roles/bigquery.jobUserandroles/bigquery.dataViewer
The key is stored encrypted per workspace and is never returned by any API — the screen shows only the service-account address it belongs to, and whether a key is present.
Test the connection — this step is not optional
A new connector is stored as Not verified yet, and every read refuses a connector that is not verified. Test connection is what turns a stored key into a usable one. Until it passes, the screen says so and nothing is read.
The test is not a ping. It probes each capability separately, through the same endpoints, the same scopes and the same host allowlist the real reads use, with a page size of one — so a green result means the real read would work, not that some Google endpoint answered:
| Capability | What is probed |
|---|---|
| Google Cloud connection | Mint a token and list log entries for the project. If this fails, the rest are not attempted — nothing else can mean anything. |
| Cloud Logging read | The same call, reported separately, because Logging IAM is granted independently. |
| Error Reporting read | Error Reporting group statistics. |
| BigQuery read | List datasets. With an empty dataset allowlist this is reported as skipped, not failed: default-deny means BigQuery is deliberately not queryable, which is a configuration choice rather than a broken integration. |
So if you granted Logging but not Error Reporting, you see exactly that, on its own line, instead of one red badge over the whole connector.
The probe is read-only like everything else here: no write scope is requested and no write endpoint is called.
Statuses
| Status | Means |
|---|---|
| Not verified yet | A key is stored, the test has not passed. Nothing is read. |
| Connected | The test passed. Reads are allowed, subject to Allow AI GCP context. |
| Reconnect required | It worked and stopped working — usually a revoked or rotated key, or IAM taken away. The last error is shown. |
| Disabled | Switched off deliberately. No reads, no health probes, configuration kept. |
Rotating the key, disabling, deleting
- Rotate by pasting a new key. Cached access tokens and the cached dataset listing are dropped immediately, so the old key stops being used at once rather than at the end of its cache lifetime. Run the test again afterwards.
- Disable stops all reads and all health probes and keeps the configuration. This is the reversible one.
- Disable & delete destroys the stored key. The screen says so before you confirm, and points you at disabling instead.
Every one of these is written to the audit trail, including whether the key was rotated.
The fields
| Field | What it does |
|---|---|
| Name | What you call this connection. |
| Project id | Optional — taken from the key when you leave it blank. |
| BigQuery dataset allowlist | Default deny. Empty means BigQuery is not queryable at all; the screen says (none — BigQuery is not queryable). |
| Log name allowlist | Optional. Empty means any log in the project; the screen says (any log in the project). |
| BigQuery scan ceiling (MiB) | The dry-run refusal threshold and the hard limit on the real run. |
| Allow AI GCP context | Off by default. Until this is on, nothing reaches an agent. |
Note the asymmetry between the two allowlists, because it is deliberate: BigQuery is default-deny (a query names its own tables, so an empty list must mean "none"), while the log allowlist is a narrowing filter (empty means the project's logs, which the credential could read anyway).
Nothing is secret when it comes back
Everything the connector returns passes two masking passes before it is stored, put in a prompt, or shown:
- By field name — anything whose key looks like an identity or a credential (email, phone, password, secret, token, api key, access/refresh/id token, authorization, cookie, session id, private key, client secret, national id, card number, CVV, IBAN, bank account) is replaced with
[redacted]. - By value — the same secret-shaped-value scanner the sandbox uses on its logs runs over what remains.
Google's own error bodies are masked before they become an error message, so a failed call cannot leak what a successful one would have hidden.
The walk is bounded too: deeply nested structures stop at a depth marker, and long arrays stop with a count of what was left out. You always know that something was cut rather than being shown a plausible-looking whole.
What it looks like on a ticket
On a BUG issue whose patch is going through QA, and only when the connector is connected and Allow AI GCP context is on, the QA note gains a section headed Google Cloud diagnostics (read-only):
- Error Reporting — top groups, as a table of count, users, service, last seen and title;
- Cloud Logging — newest first, with a line stating how many entries were read, whether the set was truncated, and that secrets are masked; then the entries themselves with their timestamp and severity.
When a service could not be reached, the note says so in place of the block — "Cloud Logging unavailable (code): message" — rather than omitting the section and letting its absence read as "nothing was wrong".
The default filter is severity ERROR and above, over a window of at most 72 hours. Read volumes are capped: at most 100 log entries and 128 KiB per read, at most 25 error groups.
Every assembly is written to the audit trail with the connector, the number of error groups and the number of log entries.
Limits worth knowing before you rely on it
- It is off in three independent places. FixControl has to have enabled the connector for your workspace (ask your FixControl contact), the connection has to be Connected (which means the test passed), and Allow AI GCP context has to be on. Miss any one and the agent stays blind.
- One connector per read. When several are configured, the first eligible one is used.
- BUG issues only. A feature request or a support question does not pull Google Cloud context.
- BigQuery has no surface yet (see above).
- Truncation is visible, never silent. A capped read says it was capped.
Related: Database connector · Change validation · Security & audit · Integrations overview