Bobbin

How it works

How Bobbin investigates — inside your own project.

Bobbin 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, 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 Bobbin reaches into your Google Cloud projectA Cloud Monitoring alert notifies a Pub/Sub channel. Bobbin'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 ownBobbin 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.

Getting in

Three paths, the same four roles.

However you grant access, Bobbin 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

Sign in with Google and the wizard grants 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. It is what we run live on the onboarding call.

Read it on GitHub

The Terraform module

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

Read it 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. Bobbin 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. If you hit the cap two months running we will suggest the next tier; nothing switches off mid-incident.

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 didtimeSeries.list · alertPolicies.get
  • roles/errorreporting.viewerwhat is failing, and since whengroupStats.list
  • roles/run.viewerwhat changed in a deployrevisions.get · services.list
Read the full trust pageRequest early access