Reading the card

Every investigation ends with a card posted to your Slack thread. This page explains what each block means, so you can read a report the way it was meant to be read — as a set of checkable claims, not a verdict to take on trust.

A finding

checkout-api — likely cause acme-prod · checkout 5xx responses

The 14:02 deploy of checkout-api (rev checkout-api-00042, commit a1b2c3d) dropped the connection pool to 2 — DB_POOL_SIZE unset, was 10. Suggested fix: restore DB_POOL_SIZE=10 in the service config and redeploy.

[Incident] · [Logs] · [Service] · [Commit] High confidence · 6 checks · 47s

Acknowledge Resolve Re-run Mute 2 hours ⋮ Open in console

The card and the thread

The split is the answer and the working, not a summary and a detail.

The card holds what you act on: what broke, where, the likely cause Nodrik found, what to do about it, and how much work is behind that. The thread holds everything you would check it against: every query Nodrik ran, the reasoning behind the confidence, the timeline, the evidence list, and the runnable command if there is one.

That is why the card is not a teaser. A card you have to open to learn anything from would be tidier in the channel and worse at 3am.

The blocks, in order

1. Service and verdict — the service, then what Nodrik found: “likely cause”, “no clear cause yet”, or “investigation stopped”. The service leads because you know which project you are in; you do not know which of your services just broke. A Test alert mark leads the line below it when the alert came from the console’s “Send a test alert” button.
2. Where — the project, the alert policy that fired, and — when more than one alert folded into this investigation — how many alerts and how many policies. That count is storm coalescing visible.
3. The finding, and the suggested fix — the cause in one sentence, with the fix under it. The fix is always framed as a suggestion, never an instruction. A runnable command never appears on the card: it is in the thread, and only at high confidence, because a command is a thing you read carefully and the card is not the surface for that. Nodrik cannot apply anything itself — read-only, permanently — so applying a fix is always your action.
4. Sources — named links straight into your own console, to the things Nodrik actually looked at: the Incident in Cloud Monitoring, the Logs query it ran first, the Cloud Run Service, and the Commit where GitHub is connected and the report names one. At most four, and the row is absent rather than empty when there is nothing to link.
5. The credential — who has this one if anybody has pressed Acknowledge, the confidence as a word on a finding, how many checks Nodrik made, and how long the whole thing took. Never a score and never a colour beyond the sidebar. An inconclusive card states no confidence at all rather than a low one: there is no hypothesis to be confident about.
6. The four actions — Acknowledge, Resolve, Re-run and Mute, with Open in console beside them. They work identically here and in the console: The console’s history.

In the thread

• What was checked — every query, revision list, error-group lookup and commit diff Nodrik ran, in the order it ran them, with a link wherever one can be built. This is what makes the time-saved claim verifiable rather than asserted, and it renders on every verdict, including one that gave up.
• Why that confidence — the sentence behind the word on the card. “High” means the evidence lines up in more than one independent way. It appears only on a finding: an honest miss has no confidence to state, so it states what would confirm it instead.
• Timeline, what changed, impact — whichever of them the investigation actually produced.
• Evidence — what the model cited, as plain named items. It carries no links, deliberately: see below.
• Suggested fix — again, with the runnable snippet where confidence is high, under “suggested — verify before running”. Where Nodrik looked up Google’s current documentation during the investigation, the command is written to agree with what it found. Then, after the report is written, the claims the fix makes — a gcloud flag, a quota name, a setting — are checked against Google’s current documentation, and the line under the fix says what happened: a quiet link to the page where the documentation agrees; a note naming the claim where it differs, beside a confidence that has been lowered one step; and “not checked against Google’s documentation” where nothing covered it. The check can lower Nodrik’s confidence in a fix and never raise it, and it never rewrites the command — a flagged command is safer than a half-corrected one. Every command Nodrik suggests is either checked against Google’s current documentation, or labelled as unchecked.

About the links

Every link Nodrik renders is built in code, from an id or from an argument of a query it actually ran. The model that writes the report is never asked for a URL and cannot supply one.

The one link that is not into your own console is the “Docs” link — the Google Cloud documentation page Nodrik read during the investigation. It is written by the code that fetched the page, from the page’s own address after checking it is on Google’s documentation hosts, and never taken from anything the model wrote. Nodrik can only open a page a search already returned.

That is not a detail. Early on, a model asked for evidence links filled them with plausible, invented console URLs — the failure mode of asking a language model for something it cannot know. The rule since: a deep link appears only where Nodrik can construct it deterministically, and where it cannot, the check is named without a link. A metric range says “Metrics: …” and stops there, because Metrics Explorer’s URL is an encoded page state that would have to be guessed at.

A guessed link that opens the wrong page costs more, mid-incident, than no link at all.

Two links you might expect and will not see:

• The alert policy. Cloud Monitoring sends its display name, not its address, so the policy page cannot be built from what arrives. The Incident link lands on the firing alert instead, which names the policy anyway.
• A pull request. Nodrik’s GitHub App holds Contents and Metadata, both read-only, and nothing else — asking GitHub which pull requests a commit belongs to needs a permission it does not have and does not want. The Commit link goes to GitHub’s own commit page, which names the pull request for you.

The honest miss

When the evidence runs out, Nodrik says so, with the same structure: what was checked, the leading hypothesis if there is one, and exactly what would confirm it.

I couldn’t determine the culprit. I checked the deploy history (no release in the last six hours), error groups (none new), and the metric timeline (latency rose gradually over 40 minutes, not a step change). No single cause stands out. Leading hypothesis: a slow memory leak — the heap graph is climbing across the window. Confirming it would need a longer observation window than this alert covers.

[Incident] · [Logs] · [Service] 4 checks · 38s

This is a good outcome, not a failure. Every AI product claims accuracy; the useful question is what it does when the evidence runs out. A confident wrong guess costs more trust than an honest “I don’t know, here is what I ruled out” — and an honest miss and a confirmed finding render with equal weight everywhere in the product, never as a lesser or apologetic result. If Nodrik only ever posted confident findings, that would be evidence it was hiding uncertainty, not evidence it had none.

When there is no card at all

The other half of reading a card is knowing what it means when one never arrives. An alert can be declined by the plan gate or by the daily cap, folded into an investigation that is already open, or silenced by a mute — and which of the four applies is decided in a fixed order: When no card appears.

Verifying a report yourself

Every read behind a card is attributable in your own Cloud Audit Logs — see Verify access for the exact query. Nothing in a card is a claim you have to take on trust; it is a claim you can check.