Your alerts, investigated.

A Cloud Monitoring alert fires. Bobbin reads your logs, metrics, deploys and commits —inside your own project, read-only — and posts the culprit to Slack with the evidence behind it.

For GCP-native teams on Cloud Run. Set up in an afternoon, by us, on a call.

Cloud Monitoring 09:33

bobbin-demo 5xx responses — request count above threshold oncheckout-api

bobby APP 09:34

Culprit found

acme-prod · checkout-api · checkout 5xx responses

The 14:02 deploy of checkout-api (rev checkout-api-00042, commit a1b2c3d) removed DB_POOL_SIZE, dropping the connection pool to 2 — order writes have failed with 500s since 14:03.

Confidence
High
Signals
6 alerts · 2 policies

Errors begin 51s after the deploy and stop on rollback · Answered in 47s · details in thread

1 reply

Illustrative report — this is the shape of every answer.

The problem

The monitoring channel nobody reads any more.

Two hundred unread alerts. Every one of them technically true, none of them telling you what broke. So the channel gets muted, and the next real incident arrives with no one watching. Alert fatigue is how monitoring quietly stops working.

An alert is a symptom

"p95 latency above 2s" tells you something hurts. It does not tell you that a deploy forty seconds earlier halved a connection pool.

The gap is the first hour

Somebody opens six console tabs and starts correlating by hand — at 3am, usually the person who knows the system least well.

Google's answer costs $15k a month

Gemini Cloud Assist investigations sit behind Premium Support. This is the version for everyone else.

How it works

Three steps, and nothing leaves your project.

  1. 1

    Your alert fires

    A Cloud Monitoring policy you already own notifies a Pub/Sub channel. You decide what is worth investigating; we never invent alerts.

  2. 2

    Bobbin investigates in place

    Using a service account you granted four viewer roles, it reads logs, metrics, error groups, Cloud Run revisions, the admin audit log, and the commits behind the deploy.

  3. 3

    The answer lands in Slack

    One incident, one thread: the culprit, a timeline, what changed, the blast radius, and a suggested fix — with the evidence it used.

Bobbin stores the report and its transcript. It does not store your telemetry — every read is transient, at investigation time, through your own APIs.

Why trust the answer

It tells you when it doesn't know.

Every AI product claims accuracy. The useful question is what it does when the evidence runs out. Bobbin returns an honest miss: what it checked, its leading hypothesis, and exactly what would confirm it — never a confident guess dressed as a finding.

Confidence is a word, with a reason attached. A suggested fix only carries a runnable command when confidence is high, and it is always framed as a suggestion to verify — Bobbin is read-only, permanently, and cannot apply anything.

Cloud Monitoring 09:33

bobbin-demo 5xx responses — request count above threshold oncheckout-api

bobby APP 09:34

No clear culprit yet

acme-prod · checkout-api · checkout 5xx responses

Leading hypothesis: an upstream dependency slowdown rather than a deploy — checkout-api has no new revisions in the window.

Status
Inconclusive
What would confirm it
payments-api latency over the same window

Checked revisions, commits, admin changes, error groups and logs · Answered in 39s

1 reply

The honest miss — shown here because it is the point.

Security

Read-only, in your project, in your audit log.

Four viewer roles, granted by you and revocable by you. Every call Bobbin makes is a read — get, list, query. The grant is your action and every read is attributable, in your own Cloud Audit Logs.

Read exactly what it can and cannot do →

  • roles/logging.viewer — what the service said
  • roles/monitoring.viewer — what the metrics did
  • roles/errorreporting.viewer — what is failing
  • roles/run.viewer — what changed in a deploy

Who it's for

A good fit, or an honest no.

Built for you if…

  • You run on GCP, mostly Cloud Run and managed services
  • You are two to ten engineers, past MVP, with real users
  • Slack is where your incidents actually happen
  • Datadog quoted you more than your compute bill

Not for you if…

  • Your logs and metrics live in Datadog, Honeycomb or New Relic
  • You are multi-cloud, or AWS/Azure first
  • You are GKE-heavy — that is a later expansion, not today
  • You want dashboards; the Slack thread is the whole product

Pricing

Every tier is the whole product.

No feature gating, unlimited users, priced per monitored project. Tiers differ in capacity and support — nothing else.

Starter

$59/month

  • 1 monitored project
  • 60 investigations a month
  • Email support

Team

$199/month

  • Up to 5 monitored projects
  • 200 investigations a month
  • Priority email / Slack Connect

Scale

$449/month

  • Up to 15, then $35 each
  • 450 investigations a month
  • Onboarding call + named contact

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.

Early access

Set up with us, on a call.

Bobbin is live and investigating real incidents today. We are onboarding a small number of GCP-native teams personally — you get the setup call, direct access to me, and the founding price.

“Google put incident investigation behind a $15,000-a-month support tier. I built the version for everyone else.”Jens Skott, Thoughtgears

We reply personally and set you up on a call — no automated onboarding yet, on purpose.