git-native runbook automation

Muster your runbooks.

Practiced procedures, not improvisation. Write incident runbooks as markdown, check them into your repo, and actually run them — with confirmation gates on destructive steps and a full audit trail of every execution.

$ curl -sSf https://mustr.sh/install | sh
★ star on github read the docs →
db-failover.md — mustr run
$ mustr run runbooks/db-failover.md
→ Step 1/3: Confirm replica lag
check passed ✓ (2.1s)
→ Step 2/3: Promote replica to primary [destructive]
This will promote db-replica-2 to primary.
Cannot be undone. Continue? [y/N] y
complete ✓ (14.3s)
→ Step 3/3: Verify writes on new primary
check passed ✓ (0.8s)
✓ run complete — logged to audit trail (run #482)
the problem

Runbooks rot in a wiki nobody trusts. mustr keeps them in the repo, and makes them runnable.

today
  • Runbook lives in a wiki page nobody's opened since the last incident.
  • It's already out of sync with the infra change that shipped last week.
  • At 3am, someone improvises from memory using a shared prod SSH key.
  • No record of what was actually run, or who ran it.
with mustr
  • Runbook is a markdown file in the same repo as the infra it describes.
  • It changes via a normal PR, reviewed like any other code change.
  • At 3am, someone runs it directly — destructive steps prompt for confirmation.
  • Every run is logged: who, what, when, and the full output.
the format

A markdown file with a couple of annotations. That's the whole format.

Frontmatter for metadata, a heading per step, and annotations that tell mustr how to execute and gate each one. No proprietary format, no vendor lock-in — it's a file you already know how to write and review.

runbooks/db-failover.md
---
title: Failover primary database
severity: high
requires:
  env: production
---

## 1. Confirm replica lag

check: pg_replica_lag_seconds < 5

## 2. Promote replica to primary

destructive: true
confirm: "This will promote {{ replica_host }} to primary and cannot be undone. Continue?"

```sh
pg_ctlcluster promote {{ replica_host }}
```
two ways to run it

Same runbook, from the terminal or a rendered view.

CLI-first for the terminal-native, but the file renders like any markdown doc — with clickable run controls — for anyone who'd rather point and click during an incident.

mustr view runbooks/db-failover.md
source — db-failover.md
---
title: Failover primary database
severity: high
requires:
  env: production
---

## 1. Confirm replica lag

check: pg_replica_lag_seconds < 5

## 2. Promote replica to primary

destructive: true
confirm: "This will promote"
  {{ replica_host }} to primary."

```sh
pg_ctlcluster promote {{ replica_host }}
```
rendered — mustr view

Failover primary database

high

env: production

1. Confirm replica lag
✓ passed
2. Promote to primary
destructive
run →
Cannot be undone. Continue?
confirm cancel
[01]

Git-native

No separate wiki to maintain. Runbooks live next to the infra they describe and are reviewed the same way as any other code change.

[02]

Safety by default

Steps marked destructive require an explicit confirmation with a custom message. Nothing runs against production silently.

[03]

Full audit trail

Every run is logged — who executed it, what steps ran, when, and the complete output. No shared keys, no guesswork after the fact.

how it compares

Where mustr sits.

Rundeck / PagerDuty RA
Runme
mustr
Setup
Enterprise deploy, complex config
npm install, minutes
One curl, minutes
Pricing
Enterprise, sales call required
Free / open source
Free / open source, plus safety & audit built in
Git-native
No
Yes
Yes
Safety gates
Yes
No
Yes
Audit trail
Yes
No
Yes

Get your runbooks out of the wiki.

Install in under a minute. No account, no sales call.

$ curl -sSf https://mustr.sh/install | sh
★ star mustr on github read the docs →