Send your alerts to Nodrik

Connecting a project gives Nodrik permission to read it. It does not send anything.

This is the step that does, and it is the one people miss: everything can look finished — green pill, four roles verified, Slack connected — and Nodrik stays silent until an alerting policy sends a notification.

What connecting actually left you

Every connection path — the console wizard, the script, the Terraform module — creates one thing in your project besides the IAM bindings:

a Cloud Monitoring notification channel of type pubsub, named Nodrik (@nodrik), pointing at the topic your workspace was given.

That channel is an address. Alerts reach Nodrik when one of your alerting policies is told to notify that address, and not before.

If you have connected a project and seen nothing since, this is almost certainly why.

Point a policy at it

Do this for the policies you actually want investigated — see which policies are worth it below if you are not sure.

In the Cloud Console

1. Go to Monitoring → Alerting and open a policy.
2. Edit, then go to the Notifications step.
3. Under Notification channels, open the dropdown and select Nodrik (@nodrik).
4. Save.

A policy can notify several channels at once, so adding Nodrik does not take the alert away from whoever gets it today. That is the recommended way to start: keep your existing channel, add Nodrik alongside it, and compare what Nodrik says against what you would have worked out yourself.

With gcloud

Find the channel once:

gcloud beta monitoring channels list \
  --project "$PROJECT_ID" \
  --filter 'displayName="Nodrik (@nodrik)"' \
  --format 'value(name)'

Then add it to a policy. This appends rather than replaces, which matters — --set-notification-channels would remove everything else:

gcloud alpha monitoring policies update "$POLICY_ID" \
  --project "$PROJECT_ID" \
  --add-notification-channels "$CHANNEL_ID"

With Terraform

If your policies are in Terraform, the channel is a data source and the policy gains one more entry:

data "google_monitoring_notification_channel" "nodrik" {
  project      = var.project_id
  display_name = "Nodrik (@nodrik)"
}

resource "google_monitoring_alert_policy" "checkout_latency" {
  # ... your existing policy ...

  notification_channels = [
    google_monitoring_notification_channel.oncall.id,
    data.google_monitoring_notification_channel.nodrik.id,
  ]
}

Check it worked

Send a test alert from Settings → Test in the console. It goes through the whole path — your channel, your topic, a real investigation — and the card arrives in Slack marked as a test.

A test alert is excluded from your monthly allowance and from the daily cap, so proving the connection works never costs you capacity you paid for. You can send ten a day.

If the test card arrives but your real alerts do not, the connection is fine and the policy is the thing to look at.

Which policies are worth connecting

Not all of them. Nodrik works best on an alert that describes something a person would have to go and investigate, and is least useful on one that is already its own answer.

Worth connecting:

• Latency, error rate and saturation on a service you deploy — the questions that start “what changed”.
• Anything that has ever made somebody open three tabs at 2am.
• Alerts on a dependency you do not own, where the useful answer is often “it is not you”.

Not worth connecting:

• Budget and billing alerts. There is nothing to investigate; the number is the message.
• Certificate expiry, quota warnings, scheduled-job reminders. A date is not an incident.
• Anything that fires on a schedule rather than on a symptom.

You can always add more later. Starting with the two or three policies that wake somebody up is a better first week than connecting everything and reading forty cards.

What happens when several fire at once

One incident is one investigation. Nodrik folds alerts about the same thing into the card already in the channel rather than posting a second one — so a storm of twenty related alerts is one card with a count on it, not twenty cards.

That is also why an alert storm does not spend your monthly allowance twenty times over. Plans and billing has the detail.

If you have no alerting policies yet

Then there is nothing for Nodrik to investigate, and connecting it has no effect — which is worth knowing before concluding something is broken.

Cloud Monitoring can create a reasonable starting set in a few clicks: Monitoring → Alerting → Create policy, then pick a metric like request latency or 5xx rate on the service you care about most. Point that policy at Nodrik (@nodrik) as above, and the next time it fires you will get a card.

Taking Nodrik off a policy

Take the channel off the policy, or delete the channel. Nodrik stops receiving from that policy immediately; nothing else about your connection changes, and no data is lost.

Removing the project from Settings → Projects is the fuller version — it stops the charge for that project too — and leaving is the complete removal.