Log inSign upDashboard

Software that maintains itself.

Your agents ship code faster than anyone can review it. Working as intended. Then it breaks at 3 a.m., and the one thing nobody kept is why that change existed at all. Drums keeps it — then reproduces the failure, repairs it, and proves the repair. You find out over coffee.

Every failurelinked to a deployEvery repairreproduced firstEvery claimcarries provenance
Book a call

Trusted by teams like

twentyfour26and other design partners

Reproduce

Working today

The failure is traced to a deploy and replayed at that exact revision.

Repair

Rolling out to design partners

Your own coding agent writes the fix. Drums proves it against the failure.

Release

In design

A small share of traffic first, then promote or roll back.

Rolling out to design partners

Bring your own agent. Drums runs the loop.

Claude Code and Codex write the repair today, OpenCode next. Drums decides what needs repairing, whether the repair worked, and whether it ships.

Don’t declare it fixed.Prove the failure is gone.

Drums starts observing only. Nothing changes until you say so.

Every claim carries how it is known — never one green check.

A repair ships alone only when every claim is verified or observed.

Observe first

Working today

0

changes before you say so

watching
every deploy

changing
nothing yet

Provenance

Working today

5 states

verified · observed · inferred · approved · unresolved

verified or observed
ships alone

inferred
goes to a person

Undo

In design

30 days

every repair reversible with one command

undo · printed with the result
drums undo --since 1hreverses it
drums stoppauses everything

Reproduction, not triage

Working today

The failing request is replayed at the exact revision before anything is written. Attribution is proven, not guessed.

Provenance, not green checks

Working today

Verified, observed, inferred, approved, unresolved. Every claim says how Drums knows it.

Git, not another database

Rolling out to design partners

Repairs land as real commits and the evidence chain attaches as a git note. git log is the audit trail.

Earned autonomy, not a settings page

In design

Each failure class climbs from observe to act alone on its own record, and drops a rung automatically after rollbacks.

Approval, not blanket autonomy

In design

Customer data, billing, permissions, and infrastructure always wait for a named person.

Agent-neutral, no lock-in

Rolling out to design partners

Claude Code and Codex write the repair today, OpenCode next. Switching agents changes nothing about the record.

Working today

Reproduce

Detect the failure from telemetry, attribute it to the deploy and the change behind it, rebuild that revision, and replay the failing request. Attribution is real, not a guess.

  • Detected from telemetry

    A failure arrives over an event webhook today, with evidence attached. Sentry, PostHog, and OpenTelemetry adapters are next.

  • Attributed to a deploy

    The failing stack trace is matched against the deploy that shipped just before it and the files it changed.

  • Rebuilt at that revision

    An isolated copy of that exact revision is rebuilt at the commit the failure first appeared on.

  • Replayed, not guessed

    The captured request runs again. If it doesn’t fail, Drums says so instead of writing a patch.

  • Intent carried forward

    In design

    The PR body, the linked ticket, or the agent prompt behind the change is kept as what it was supposed to do.

How attribution works
drums watch
41 errors on POST /api/checkout in 4 minutes · 3.1% of sessions.
failure
signal:     POST /api/checkout · 500
first_seen: 14:18:31
volume:     41 errors in 4 min
sessions:   3.1%
sources:    sentry · posthog · synthetic run
 
claim:      failure_detected   observed
Detection comes from the telemetry you already run.
Nothing has been changed. Drums is still only watching.
Reproduction is what turns an attribution into a fact.
The loop, end to end
Rolling out to design partners

Repair

Your own coding agent writes the fix. Drums hands it the reproduction and the acceptance criteria, then checks the patch against the original failure and the behaviour around it — never against the agent’s report.

How a repair is verified
CheckResult
original failing request
✓ verified · returns 200
adjacent endpoints
✓ verified · 6 unchanged
checkout e2e suite
✓ verified · 14 specs

Every claim bound to the exact revision, environment, and actor.

In design

Release

Ship the repair to a small share of traffic, confirm the original failure is gone and nothing else moved, then promote or roll back. Repairs stay reversible with one command for 30 days.

Repair verified
Canary
Compare
PromoteRecovered
RevertRegressed
Every step, decision, and revert lands in the record.
Stop and undo

Maintenance that isn't a failure? There's a routine for it.

Scheduled work described the way you would describe it to a colleague. Drums runs it, reports what passed, and leaves you one thing to look at.

Dependency upgrades

Mondays 06:00

Add

Flaky test hunt

Nightly

Add

Dead feature flags

1st of month

Add

Security advisories

On publish

Add

Lockfile drift

Weekly

Add

Deprecated API calls

Monthly

Add

Unused dependencies

Monthly

Add

Bundle size creep

Nightly

Add

Dependency upgrades

Mondays 06:00

Add

Flaky test hunt

Nightly

Add

Dead feature flags

1st of month

Add

Security advisories

On publish

Add

Lockfile drift

Weekly

Add

Deprecated API calls

Monthly

Add

Unused dependencies

Monthly

Add

Bundle size creep

Nightly

Add

Stale branches

Weekly

Add

Snapshot refresh

Nightly

Add

Type coverage

Weekly

Add

Audit export

1st of month

Add

Docs drift

Weekly

Add

Broken links

Weekly

Add

Slow query report

Nightly

Add

Revert drill

Quarterly

Add

Stale branches

Weekly

Add

Snapshot refresh

Nightly

Add

Type coverage

Weekly

Add

Audit export

1st of month

Add

Docs drift

Weekly

Add

Broken links

Weekly

Add

Slow query report

Nightly

Add

Revert drill

Quarterly

Add
Browse the routines

Built so trust survives the first mistake.

Provenance on every claim, autonomy earned per failure class, one command that stops everything, and approval required where a mistake would cost the most.

Provenance on every claim Working todayEvery claim carries how Drums knows it — verified, observed, inferred, approved, or unresolved.Boundaries in plain language In designProposed from your reverts, code owners, and migration history. Corrected in a sentence, not a config file.Git is the record Rolling out to design partnersRepairs land as real commits and the evidence chain attaches as a git note that travels with the repository.Approval where it counts In designCustomer data, billing, permissions, and infrastructure always wait for a named person.Verified against the failure Working todayThe original failing request, the tests around it, and the endpoints next to it — not the agent’s summary.Reproduction before repair Working todayAn isolated copy of that exact revision, the captured request replayed. The guess becomes a fact before anything is written.Canary before promotion In designA small share of traffic first. Promotion waits until the original failure is gone and nothing new appears.One command to stop In designdrums stop pauses every environment; drums undo --since reverses what shipped inside a window.Shadow mode Rolling out to design partnersRepairs generated and verified in isolation, never shipped, so you can compare them against what your team actually did.Autonomy earned per class In designObserve → shadow → propose → act alone, promoted on track record and demoted automatically after rollbacks.One binary Rolling out to design partnersA CLI, a git remote, and an MCP tool inside Claude Code and Codex. No new place to go.Built on your systems Working todayA webhook in today — Sentry, PostHog, and OpenTelemetry adapters next. Your existing deploy platform out. Drums never becomes your deploy target.A webhook in today — Sentry, PostHog, and OpenTelemetry adapters next. Your existing deploy platform out. Drums never becomes your deploy target.

Ships wherever you work

One binary. A CLI, a git remote, an MCP tool inside Claude Code and Codex, and annotations in the editor gutter. git log stays the audit trail.

Local

Free, forever

Run the loop on your own machine, on as many repositories as you like. Observe-only by default, the record stays local, and nothing leaves your boundary.

Install

Design partner

An eight-week pilot with a small number of teams — one application and one failure class at a time, with the record reviewed together every week.

Book a call

Production

An annual subscription for production applications after the pilot: private deployment, reproduction inside your own infrastructure, identity-bound approvals, and a signed audit export.

SOC 2 Type I — in progress

GitHubGitLabCIKubernetesObservabilityIncidentsJiraLinear
Book a call

The engineer is on the loop, not in it.

You read about the repair after it worked — and it stays one command away from undone.

Book a callInstall the CLI

Self-healing software, answered plainly

What Drums does, what it refuses to do on its own, and where it stops.

What is self-healing software?+

Software that detects its own production failures, works out which change caused them, fixes them, and proves the fix worked — without a person having to notice first. Drums does that as a loop: detect, attribute to a deploy, reproduce at that exact revision, repair with your own coding agent, verify against the reproduction, then propose the change.

How does Drums fix production bugs automatically?+

It replays the failing request against a container built at the commit that introduced the failure. If it does not fail there, Drums says so and stops rather than guessing. If it does, the reproduction becomes the acceptance test the repair has to pass — so a fix is only called verified when the original failure has actually stopped.

Does Drums deploy to production without approval?+

No, not by default. Every repair stops at a pull request and waits. Shipping on its own is earned per failure class: five consecutive clean ships, a human running drums authority promote, and automatic demotion the first time something goes wrong. There is no flag that skips the ladder.

Which coding agents does it work with?+

Claude Code and Codex today, OpenCode next. Drums drives the CLI already authenticated on your machine — it never resells model access and never asks for an API key in local mode. Deciding what needs repairing and whether the repair worked is the product; writing the patch is not.

How is this different from Sentry or Datadog?+

Those tell you something broke. Drums starts where they stop: it takes the error, links it to the deploy that caused it, reproduces it, and fixes it. It consumes your existing telemetry rather than replacing it, and it has no graphs, alert rules, or on-call schedule of its own.

What does it cost?+

The whole loop — detect, attribute, reproduce, repair, verify, propose — is free forever on your own machine, on as many repositories as you like, with no account. The one paid thing is act-alone authority: letting Drums ship a failure class without waiting for you.