The console's history

The Slack thread is where an investigation lands and it is still the primary artefact. The console’s history exists for the two people the thread does not serve: whoever was not in the channel, and whoever is looking three weeks later.

It is Investigations in the console’s own navigation, and every role can read it — including read-only. Acting on what you find there needs at least member access.

The list

One row per investigation, newest first, with five columns:

• Opened — when the first alert arrived.
• Project / service — the service the alert named, with a Test pill beside it when the investigation came from the console’s “Send a test alert” button. The mark rides on this cell rather than becoming a column of its own, which would be empty for almost every row.
• Policy — the Cloud Monitoring alert policy that fired.
• Status — reported, running or failed.
• Alerts — how many alerts this one investigation is made of. A number above one is storm coalescing visible: it is the difference between what Cloud Monitoring recorded and what your channel received.

Two filters sit above it — project or service, and status — and their options are built from the rows themselves rather than from a separate lookup, because there is no separate lookup. There is no free-text search over reports or transcripts; that is post-GA, and until then filters are what there is.

It is a bounded list, not a complete archive. The most recent few dozen investigations load, and the filters narrow what has loaded rather than querying further back. A busy month can therefore push an older investigation out of reach of the console — if you need one from further back than the list goes, ask us.

Nothing that was declined appears here at all. An alert refused by the plan gate or the daily cap, and an alert folded away by a mute, never open an investigation, so there is no row for them and no record to find: When no card appears.

One investigation, in full

Clicking a row opens the report at its own address, and the address is the point — it is what makes this an archive rather than a list. Paste it into the incident channel, a ticket, or a post-mortem and it resolves for anybody in your workspace.

The page renders the report in the same shape as the Slack card — verdict, evidence, suggested fix, confidence — because one incident should have one mental model however it is read. Reading the card explains what each block means and applies to both surfaces equally.

Two things on the page are worth knowing about specifically:

• Evidence and “What was checked” are two lists, deliberately. Evidence is what the model cited, and it carries no links. “What was checked” is built in code from Nodrik’s own tool calls, so every link in it is deterministic and real — a deep link into your console, which is the open differentiator: check the working, not our word for it. They are kept apart so that nothing ever invites a model to fill in a URL.
• A test alert says so on the page, not only in the list, and says that it was not counted against your allowance. Somebody arriving from a link weeks later has no memory of pressing the button, and the one number they might check their allowance against would otherwise not add up.

A still-running investigation shows what it is: “Nodrik is working through the evidence now”, rather than an empty panel that reads as a bug. Where Slack gave us a permalink, there is an Open the Slack thread button.

The transcript behind a report is kept — it is what the card is rebuilt from — but the console does not display it. What Nodrik examined reaches you as the “What was checked” list.

A link that is not yours behaves exactly like a link to nothing. Both answer “there is no investigation at this address for your workspace”, identically and on purpose: telling them apart would confirm that an id exists, which is a membership oracle over every investigation we hold.

The four actions work the same on both surfaces

Acknowledge, Resolve, Re-run and Mute are on the Slack card and on this page, and both call the same decision underneath — two implementations would be two sets of rules, and the one that got used less would be the one that was wrong.

Action	What it means
Acknowledge	A human has this one. It says so on the card and here, so the channel can stop asking
Resolve	The reader is done with the card. There is no Reopen — a re-run is the way back from a mis-click
Re-run	Ask again, on the same alerts. A fresh investigation, in the same Slack thread, editing the same card
Mute	Stop investigating this cause for a while — see muting

None of this is incident management. Nothing here pages anybody, holds a schedule, or writes anything to your Google Cloud project. Acknowledge and resolve are Nodrik-side state about a Nodrik-side report; a mute stops Nodrik investigating a cause and leaves your alert policies exactly as you configured them. “Who is on this” is a property of the card so the card can stop asking — it is not the beginning of a rota.

A few honest edges:

• A refusal is not an error. Two people pressing Acknowledge is the normal shape of an incident, and the second one is told “Sam already has this one” rather than shown a failure. In Slack that reply is ephemeral — only the person who pressed it sees it, because the channel already knew.
• A re-run is a new investigation, which is exactly why the daily cap and the plan gate apply to it the same way they apply to an alert. A refused re-run says which of the two stopped it. It is also the one investigation an impatient finger can produce on demand, so pressing it twice is deduplicated rather than billed twice.
• Re-running a test alert is still a test. It stays excluded from both meters rather than quietly becoming billable usage.
• Muting is the one action a resolved investigation still accepts. A cause outlives the card that reported it.
• Pressing a button in Slack does not post to the thread. The card updates in place and gains one line — “acknowledged by Jens · 3 min ago”. A reply per press would be the saturation the product exists to remove, one level down. The exception is a re-run, which puts its new working in the thread, because that is evidence rather than a notification about a click.

The two surfaces differ in exactly one way, and it is worth being direct about it: Slack has no notion of your Nodrik roles. Anybody who can click in the channel Nodrik posts to can press these buttons; the channel is the boundary there. In the console, the same actions need member access and a read-only user changes nothing. See Your team.

Every action anybody takes is recorded in Team ▸ History — who did it, which identity they used, and the role they held at the time.

What happens to it

Investigations are kept in europe-west1, redacted before they are written, for as long as your workspace exists. They are deleted with it: see Leaving Nodrik, and Security and trust for what persists and what never does.