Now showing · Schema change · 1:16

Claude investigates. Your team decides.

Piperoom is a self-hosted incident room for Debezium and Kafka pipelines on Postgres or MySQL. When one breaks, a room opens and Claude investigates with read-only tools while your team watches and steers. A fix runs only after every owner it touches approves it. The same agent also sets a new pipeline up from an empty directory, so the first incident is the one it prevents.

Request early access

Pre-1.0 · Early access · Runs in your environment

0:00 / 1:16
0:00 · A room opens

With Arjun, on call · Priya, schema-registry owner · Kabir, consumer owner · Meera, next shift · and Claude, read-only.

Dramatised from Piperoom's schema-change demo. Times are illustrative.

Read the transcript

1. A room opens

0:0009:41. A migration changes orders.amount to numeric(12,2).

0:03Schema Registry rejects the new schema with a 409. Debezium task 0 fails.

0:06The connector still reads RUNNING. New rows stop reaching the warehouse.

0:09The watcher sees the failed task and opens a room. Arjun is on call.

2. Claude investigates

0:12A first look arrives, marked unverified. Then Claude starts the real investigation.

0:15Every step is a read-only tool call: connector status, schema versions, a diff.

0:18Consumer lag is zero, so the consumer is ruled out. The DDL log shows the ALTER.

0:22Tool output stays data: instructions hidden in it are flagged, not followed.

3. Everyone watches, one drives

0:26Anyone can watch the room live. Kabir questions step 1, right on the step.

0:29Only the driver steers. Kabir's idea becomes a suggestion, not a command.

0:33Arjun drives, so he sends it on. Claude checks: the connector config is unchanged.

4. A fix is proposed

0:38Root cause: the ALTER on orders.amount breaks BACKWARD compatibility.

0:41The hypothesis cites the steps it rests on. Then Claude writes a fix it cannot run.

0:45Two steps, each tagged with its layer, a rollback, and a fingerprint of the plan.

5. Every owner approves

0:50Priya owns the Schema Registry. She approves her step, bound to that fingerprint.

0:53Arjun approves for Kafka Connect. With both owners in, the fix can run.

0:56Compatibility goes to NONE and task 0 restarts. Then Claude checks the recovery.

1:00New rows reach the warehouse. A follow-up to restore BACKWARD waits for Priya.

6. Shift change

1:04Shift change. Arjun hands off, and Claude writes the summary from the room log.

1:07What broke, why, what's done, what's ruled out, what's still open, and the risks.

1:11Meera accepts and drives. Priya approves the restore, and the room closes verified.

Read the narrator's script

1. A room opens

0:009:41. Someone changes one tiny column… and a pipeline quietly stops.

0:06The status still says running. It always does.

2. Claude investigates

0:12So a room opens, and Claude gets to work. It can look, but it can't touch.

0:17It rules things out, one by one. And when a log line tries to give it orders? It just doesn't listen.

3. Everyone watches, one drives

0:26Your whole team can watch it think. Kabir has a hunch.

0:29But only one person drives. So Kabir suggests, and Arjun decides.

4. A fix is proposed

0:38Found it. One schema change broke everything downstream, and Claude shows its work.

0:44Then it writes the fix… but it can't run it. That part's up to you.

5. Every owner approves

0:50Priya owns the schema, so she approves this exact fix. Not a version of it. This one.

0:57Arjun signs off, the fix runs, the data flows again, and Claude makes sure.

6. Shift change

1:04Six o'clock. Arjun hands over to Meera, with the whole story in one summary.

1:09Go home, Arjun. Piperoom: Claude investigates. Your team decides.

01 — How a room works

One room, from the first alert to the hand-off.

Every room is an append-only log of events. Anyone who joins late sees it replay, then follows along live.

  1. 01

    A room opens itself.

    A built-in watcher spots a failed connector, an inactive replication slot or growing WAL and opens a room. Alerts from Alertmanager, Grafana, PagerDuty, Datadog or any signed webhook open one too.

    The watcher only writes log lines until you switch it to rooms.

  2. 02

    Claude investigates. Everyone watches.

    Claude works through read-only tool calls you can follow step by step. Anyone can comment. One driver steers, and everyone else's ideas arrive as suggestions the driver can send on or decline.

  3. 03

    Owners approve the exact fix.

    Claude can only propose. Each step names the layer it touches, and the fix runs only after every owner of those layers approves that exact proposal.

  4. 04

    Hand off without losing the thread.

    At shift change Claude writes what broke, why, what's done, what's ruled out, what's still open and the risks. The driver role moves when the next person accepts.

02 — The investigation

Watch the reasoning, one tool call at a time.

Claude works through read-only tools you can follow step by step: what it called, with what input, and what came back. The hypothesis cites the steps it rests on, and any term the cited steps don't show is marked.

  • 43 read-only tools across Kafka Connect, Schema Registry, Kafka, Postgres, your warehouse and batch jobs.
  • Alerts, logs and record values reach the model only inside an untrusted wrapper. Suspected instructions are flagged, not followed.
  • Anyone can comment on a step. The driver steers; the driver's lease lasts 30 minutes and renews whenever they act.
InvestigationInvestigating · step 6
First looktriage, unverifiedTask 0 of pg-orders-connector failed on a Schema Registry error.
1
Check the Debezium connector
connect_statusconnector=pg-orders-connector
tool output · untrustedTask 0: FAILED … incompatible with an earlier schema for subject "pg.public.orders-value" … error code: 409
KabirWrong service? I'd expect Connect to be down, not the schema.
ClaudeConnect is up; task 0 is failed on a Schema Registry compatibility error.
2
Inspect the Schema Registry subject
schema_registry_versionssubject=pg.public.orders-value
tool output · untrustedversions [1] … compatibility BACKWARD
3
Diff the attempted schema against v1
schema_registry_diff
tool output · untrustedamount: int → bytes(decimal 12,2)
4
Check consumer lag
kafka_consumer_laggroup=order-syncruled out · consumer
tool output · untrustedorder-sync: Stable, 1 members, total lag 0
5
Check the DDL log
pg_recent_ddl
tool output · untrustedALTER TABLE public.orders: ALTER TABLE orders ALTER COLUMN amount TYPE numeric(12,2)
6
Check what changed before the alert
what_changed
tool output · untrustedDDL 90 s before the alert · connector config change · schema version
Suggestions
KabirCheck the connector config first, not the topic.

You are Arjun, the driver. Kabir can't steer, so his idea waits for you.

Hypothesishigh confidencelow 09:45 high 09:47

A schema change to orders.amount broke the pg-orders-connector on a Schema Registry incompatibility; no new rows reach the warehouse.

based on
Terms the cited steps do not show: none

The First look verdict text is illustrative; steps, tools and outputs follow the schema-change demo.

Read shelf · 43 tools · kind read

Connect · 4
connect_list_connectorsconnect_statusconnect_configdebezium_metrics
Schema Registry · 3
schema_registry_subjectsschema_registry_versionsschema_registry_diff
Kafka · 12
kafka_topic_offsetskafka_list_groupskafka_consumer_lagkafka_find_by_keykafka_topic_configkafka_cluster_healthkafka_aclskafka_throughputkafka_partition_rateskafka_dup_keysdlq_peektls_cert_expiry
Postgres source · 8
pg_replication_slotspg_recent_ddlpg_long_transactionspg_rowpg_publication_tablespg_connector_scope_gappg_streaming_livenesspg_toast_risk
Warehouse · 3
warehouse_freshnesswarehouse_rowwarehouse_load_errors
Cross-pipeline · 6
pipeline_maptrace_recordreconcilewhat_changedsimilar_incidentsrunbook_lookup
Batch · 7
dag_runstask_instancestask_log_taildag_schedule_gapdbt_run_resultsdbt_model_lineagedbt_model_sql

Write actions are not on this shelf. They sit in a separate registry and run only from an approved proposal.

03 — The approval

Nothing runs until every owner says yes.

Claude can only propose. Each step names the layer it touches, and every owner of those layers approves that exact proposal. Each approval carries a SHA-256 fingerprint of the proposal, so an edited proposal no longer matches. After the fix runs, Claude re-reads the touched layers and checks that new rows arrive.

Try it: approve as Arjun, or change one parameter first.

Waiting for kafka-connect · 1 of 2 approved
ProposalsNeeds approval · 4mAgent waiting · 1 of 2 approvals
Set subject compatibility to NONE and restart the connector task
Step 1schema_set_compatibilityschema-registry
subject
pg.public.orders-value
level
NONE

Allow the new decimal schema to register under the same subject.

Step 2connect_restart_taskkafka-connect
connector
pg-orders-connector
task
0

Restart Debezium task 0 so it picks up the new schema.

Rollback: set compatibility back to BACKWARDRequired layers: schema-registry · kafka-connect
FingerprintApproving exactly this
205a 8899 … f485

if the steps change, this fingerprint changes and your approval is void

Proposed byClaude (agent)
Schema-registryPriya · approved 09:49
Kafka-connectArjun · pending
Fingerprint205a…f485
RevA
1 of 2 approved
Approve and run
Runs after the last approval.
Pipeline, source to sink
SourceordersdegradedPriya
Connectorpg-orders-connectorfailedArjun
Schema subjectpg.public.orders-valuedegradedPriya
Topicpg.public.ordersunknownArjun
Consumerorder-synchealthyKabir
Sinkanalytics.ordersdegradedMeera

Fingerprint computed in your browser over the steps shown. Piperoom's own also covers the room, the proposal id and the risk, in RFC 8785 form.

Desk 1
Priya: approved Priyaschema-registry
Desk 2
Arjun: pending Arjunkafka-connect
Change one parameter

Write actions · 15 · run only from an approved proposal

kafka-connectconnect_restart_taskconnect_restart_connectorconnect_resume_connectorconnect_pause_connectorconnect_update_connector_configconnect_snapshot_table
schema-registryschema_set_compatibilityschema_register
kafkadlq_replaykafka_replay_range
consumerkafka_reset_consumer_offsets
postgrespg_drop_replication_slotpg_add_publication_tablepg_snapshot_signalpg_resnapshot_rows

Write mode is off by default. Proposals and approvals work, but nothing runs until you turn it on.

04 — The hand-off

Shift change without the scroll-back.

When the driver hands off, Claude writes the summary from the room log: what broke, why, what's done, what's ruled out, what's still open and the risks. It is checked against the log before anyone accepts, and the driver role moves only when the next person does.

HHand-offs never start on their own. The driver presses H and picks who takes over. The summary stays pinned in the room for everyone who joins later.

Arjun · local 18:00
Shift 1 summary from Arjun to Meera
What brokeDebezium task 0 failed after orders.amount was altered to numeric(12,2).
WhyNew schema is incompatible under BACKWARD compatibility for subject pg.public.orders-value.
DoneSet compatibility to NONE · Restarted task 0 · Warehouse caught up
Ruled outKafka brokers · Consumer group config
Still openConsider pinning decimal.handling.mode · Restore BACKWARD (waiting for schema-registry)
RisksBACKWARD compatibility is off until re-enabled
Checked against the room log · no issues
You are Meera
Meera · local 07:00
room clock 10:00 UTC · times illustrative

05 — Trust

It can read. It can't write.

Piperoom is built so Claude can be in the room without being able to touch the pipeline. Each guarantee names the file on main that enforces it.

T1

Read-only by construction

Every investigation tool sits in a read-only registry that refuses anything else. Client interfaces are split into readers and writers, and writes live only in a separate set of actions. Source Postgres reads run in a READ ONLY transaction that is rolled back. Every read and every action is checked against the room's own pipeline.

Proof: internal/tools/tool.go · internal/clients/postgres · internal/tools/scope.go

T2

Approval per layer, bound to the exact plan

Each step names its layer, and the approver must own that layer. The approval carries a SHA-256 fingerprint of the proposal: without it the server answers 400, with a different one 409 params_mismatch. Each write action has a preview and a rollback.

Proof: internal/room/params_hash.go · internal/room/service_proposals.go · internal/actions/preview.go

T3

Secrets masked, untrusted text kept as data

Secrets are masked in tool summaries, error traces and record values before they reach the prompt, the room log, Slack or an export. Redaction is partial: names and timestamps still appear, and redacted tool summaries do reach your Claude endpoint. Alerts, logs and record values reach the model only inside an untrusted wrapper.

Proof: internal/redact/redact.go · internal/agent/prompt.go

T4

An audit trail you can export

Every room is an append-only event log; events are never edited. Export a room as JSON with an X-Piperoom-Export-SHA256 integrity header, or start from the post-mortem draft. Export is limited to approvers and auditors.

Event types are real; sequence numbers are illustrative.

Proof: internal/events/events.go · internal/room/service_export.go

T5

Runs where your pipeline runs

Self-hosted: a Docker image, Docker Compose, a Helm chart or Terraform for GCP. Sign-in with OIDC, with member, viewer and auditor roles. Credentials are set per pipeline, from environment variables or files. Claude runs through the Anthropic API, AWS Bedrock or Google Vertex AI, with token and cost budgets per room and per pipeline.

Dockerfiledocker-compose.pilot.ymlhelm/piperoomterraform/gcpPiperoom your Claude endpoint

Proof: deploy/ · internal/httpapi/auth_oidc.go · internal/config/config.go

Slack is outbound only: one thread per room. Nothing typed in Slack reaches a room, and approvals happen only in Piperoom.

06 — Works with

Works with the pipeline you already run.

CDC path
PostgreSQLMySQLDebezium on Kafka ConnectKafkaConfluent Schema RegistryPostgres warehouseTLS and SASL
Warehouses
SnowflakeBigQueryDatabricks SQLClickHouse
Batch rooms
Apache Airflow 2.xdbt
Alerts in
AlertmanagerGrafanaPagerDutyDatadogsigned webhook
Out
Slack, outbound, one thread per room
Claude via
Anthropic APIAWS BedrockGoogle Vertex AI

MySQL sources are new in this release. MongoDB, Oracle and SQL Server sources are in progress: the read-only clients are merged and the setup drivers are in review. Not supported today: two-way Slack, Microsoft Teams, or a hosted plan. Product names belong to their owners.

07 — Shadow mode

Try it silently first.

Switch on shadow for one pipeline. Your team runs incidents exactly as today, and nobody sees Claude's work until the room closes.

Your team works the incident.

The room opens as usual. People investigate, steer and close it.

Claude works in the dark.

On the same alert, Claude investigates with read tools only, proposes nothing and writes to a separate shadow log.

Label first, then grade.

After the room closes, someone on the pipeline names the layer and the cause, blind. Then they open Claude's answer and grade it: right layer or not, and root cause yes, partial or no.

Grades roll up in GET /api/shadow/metrics on your own server. Piperoom publishes no benchmark numbers.

How a pilot grows, if you want it to

  1. 01

    Install

    docker compose · helm · terraform

    Run it on your own infrastructure. Sign in through your OIDC provider.

  2. 02

    Shadow

    shadow: {enabled: true}

    Claude works silently on one pipeline. You grade every answer.

  3. 03

    Rooms

    PIPEROOM_WATCH_MODE=rooms

    The watcher opens rooms and your team works them with Claude. By default the watcher only writes log lines.

  4. 04

    Write mode

    PIPEROOM_WRITE_MODE=on

    Approved fixes run. It stays off until you turn it on.

08 — Early access

Arjun, Priya, Kabir and Meera are Piperoom's demo users.

Start with one pipeline, in shadow mode.

We studied 722 Debezium incidents engineers reported in public. Four in five began at setup, and most of the rest were failures nobody could see into. Piperoom is built for the engineer who gets paged when the warehouse goes stale. It is pre-1.0, and we onboard a few teams at a time, each on one pipeline, in shadow mode first. If you run Debezium and Kafka in production on Postgres or MySQL, request access below.

What it involves

  • You host it: Docker Compose, a Helm chart or Terraform for GCP.
  • You create read-only credentials for one pipeline.
  • Write mode stays off, so no fix can run.
  • After each closed room, someone labels the cause and grades Claude's answer.
  • Redacted tool summaries go to the Claude endpoint you choose: Anthropic API, AWS Bedrock or Google Vertex AI.

What you get

  • We install it with you on a call and stay on the thread while it runs.
  • Your incidents decide what we build next, and you hear about it first.
  • Free during early access, with a review at the end of one quarter: you tell us whether it earned a place.
  • Your grades and room logs stay on your server. Piperoom publishes no numbers you did not agree to.
Your CDC path

Goes to the Piperoom team. You'll also get a copy of the summary to keep.

Can Claude change my pipeline?

Not by itself. Its tools are read-only. A fix runs only after every owner of the layers it touches approves that exact proposal, and only when write mode is on. It is off by default. If you list an action under auto_approve for a pipeline, a matching proposal gets a visible countdown that the driver or an owner can cancel; it still needs write mode on. The list is empty unless you configure it.

Where does my data go?

Piperoom runs in your environment. Redacted tool summaries go to the Claude endpoint you configure. If you connect Slack, it gets one outbound thread per room.

Which systems does it read?

PostgreSQL and MySQL sources through Debezium on Kafka Connect, Kafka, Confluent Schema Registry, and Postgres, Snowflake, BigQuery, Databricks SQL or ClickHouse warehouses. Batch rooms read Airflow 2.x and dbt.

Is it open source?

No. It is source-available: the code is published so you can read how the guarantees are enforced, starting with the read-only registry (internal/tools/tool.go), the approval fingerprint (internal/room/params_hash.go) and redaction (internal/redact/redact.go). All rights are reserved.