NodrikStart your 14-day trial

How it works

How Nodrik investigates — inside your own project.

Nodrik does not pull your logs and metrics into a platform of its own. When one of your Cloud Monitoring alerts fires, it reaches into your Google Cloud project — through APIs, using roles you grant and can revoke — reads what it needs to answer one question, and leaves. Everything below is that reach-in model, in the order it actually runs.

The three steps on the homepage are the summary. This is the mechanism: the boundary the investigation never crosses, what a report contains, the three paths in, and what a Slack thread costs against your plan.

The reach-in model

One boundary, one truth.

Alert to Pub/Sub to an investigation that runs inside your own project, read-only, to a report in Slack. The dashed line is not decoration — it is the one thing this page exists to show.

How Nodrik reaches into your Google Cloud projectA Cloud Monitoring alert notifies a Pub/Sub channel. Nodrik's investigation runs inside your own Google Cloud project, reading logs, metrics, error groups and Cloud Run revisions read-only. The report is posted to Slack. No telemetry leaves your project.YOUR GOOGLE CLOUD PROJECTAlertCloud MonitoringPub/Suba channel you ownNodrik readslogs · metrics · errorsrevisions · commitsread-onlySlackone incident, one threadThe report leaves.Your telemetry does not.Every read is transient, at investigation time, through your own APIs.

What you get

The anatomy of a report.

Rendered by the same code that posts to Slack. Four blocks on the card, in the same order for every verdict, and the working in the thread.

incidents

Cloud MonitoringAPP10:22

orders 5xx responses — request count above threshold onorders-api

nodrikAPP10:23

orders-api — likely cause

acme-prod · orders 5xx responses

Suggested fix: Restore the roles/pubsub.publisher IAM binding on topic projects/acme-prod/topics/order-events for the service account used by the orders-api Cloud Run revision.

High confidence · 35s

in thread

High confidence — Audit logs confirm the exact IAM policy modification on the Pub/Sub topic at 10:15:34, immediately preceding the publish errors and 500 status codes that started at 10:17:04 on revision orders-api-00049-49p.

Timeline

  • 10:15:34 IAM policy updated on Pub/Sub topic projects/acme-prod/topics/order-events via SetIamPolicy.
  • 10:17:04 Cloud Run service orders-api (revision orders-api-00049-49p) begins failing to publish events and returning 500 errors.
  • 10:22:29 Monitoring alert triggers due to 5xx response rate.

What changed

  • config — IAM policy modified on projects/acme-prod/topics/order-events at 10:15:34.

Impact

Requests to orders-api that trigger Pub/Sub event publishing fail with HTTP 500 internal server errors.

Evidence

  • IAM policy change on Pub/Sub topic — An IAM policy update (google.iam.v1.IAMPolicy.SetIamPolicy) was applied to Pub/Sub topic projects/acme-prod/topics/order-events at 10:15:34.465.
  • Cloud Run logs show event publish failures — Beginning at 10:17:04.421, service logs for Cloud Run revision orders-api-00049-49p began logging ERROR event publish failed.
  • Alerting metric 5xx spike — Cloud Run metric run.googleapis.com/request_count recorded HTTP 500 status responses on orders-api-00049-49p, triggering the alert at 10:22:29.

Suggested fix

Restore the roles/pubsub.publisher IAM binding on topic projects/acme-prod/topics/order-events for the service account used by the orders-api Cloud Run revision.

suggested — verify before running

A real investigation from our demo environment, names changed. No deploy and no commit — the cause was in the audit log.
  1. The card states its case. Service first — you know which project you are in, not which service just broke. Then where exactly, then the one sentence worth waking up for, then what that sentence is grounded in: confidence as a word with a reason, and the time it took.
  2. The thread proves it. Timeline, what changed, impact, evidence — each item names the log query, revision or audit entry it rests on. In a live thread every check Nodrik ran is a link you can open, so a reader who disagrees with the conclusion is still twenty minutes ahead.
  3. Suggested, never applied. A fix is text, stamped “verify before running”. A runnable snippet appears only at high confidence. Nodrik holds no write permission and cannot apply anything.
  4. Once, in one thread. Nodrik replies to the alert that opened the thread and then stays quiet. No heartbeats, no “still looking”. When the evidence runs out, the reply is an honest miss with the same four blocks.

Getting in

Three paths, the same four roles.

However you grant access, Nodrik ends up with the same identity and the same four viewer roles — no path buys it more, and none of them buys you less transparency.

The console wizard

Gated on Google OAuth verification

A separate Google sign-in — proving you can grant IAM roles on the target project, not the sign-in you use for the console itself — lets the wizard grant the same four roles for you through a transient OAuth consent, no gcloud to run. It is not available today: Google's sensitive-scope verification is a weeks-long process we cannot skip, and this page will not pretend otherwise.

The auditable script

Plain, commented bash wrapping the same gcloud steps 1:1 — readable before you run it, nothing hidden in a binary. The console shows it with your values filled in.

Read the script on GitHub

The Terraform module

The same grants again, wired for teams that provision Google Cloud by pull request rather than by hand.

Read the module on GitHub

All three come from one manual doc — the spec and the transparency artefact. An IAM change edits that doc first, then both implementations, in the same change.

Coalescing

One incident, one thread.

An alert storm is still one incident. Nodrik folds it before it reaches Slack, so a bad rollout does not turn into six competing conversations.

Before — six alerts, six channel posts

  • checkout-api-00042-abcd revision_name
  • checkout-api-00042-efgh revision_name
  • i-4f19a2 instance_id
  • i-88b3c7 instance_id
  • checkout-api-7f3a-x9k2 pod_name
  • task-3 task_id

After — one open investigation

checkout-api · 5xx threshold1 coalescing key, 1 thread

The fold is service-level: it strips revision_name, instance_id,pod_name, task_id and version_id — a real coalescing key, not a "similar alerts" guess. A storm counts once against your plan's investigation cap.

Fair use

Included investigations, plain numbers.

Every tier includes a monthly allowance of investigations, and coalescing decides what actually counts as one.

An alert storm counts once — coalescing folds it into a single investigation. Go past your monthly allowance and nothing switches off mid-incident: we tell you, and the difference is not billed. Only if you finish 2 of 3 billing periods over it do we add the investigations you are actually using to your subscription, a week after telling you — so one bad month costs nothing.

Full pricing and the plain-numbers FAQ →

What it can read

Four roles, checkable at the verb level.

The same four viewer roles shown on the homepage and on /security.

  • roles/logging.viewerwhat the service saidentries.list
  • roles/monitoring.viewerwhat the metrics did, and what else is firingtimeSeries.list · alerts.list · alertPolicies.list · notificationChannels.list
  • roles/errorreporting.viewerwhat is failing, and since whengroupStats.list
  • roles/run.viewerwhat changed in a deployrevisions.list
Read the full trust pageStart your 14-day trial