Skip to content
Docs Flowy
Runbooks and on-call

The page you open at 3am
is the one nobody has read since it was written.

A runbook is the only document whose failure mode is measured in minutes of downtime. It is also the one least likely to be read on a normal Tuesday, which is exactly when you would find out it is wrong.

The incident starts. Somebody finds the runbook, and the third step references a dashboard that was decommissioned, a script that moved, and an alias for a team that no longer exists. None of that was visible yesterday.

Runbooks rot differently from other documentation. A spec that goes stale is read by somebody with time to notice; a runbook is read under pressure by whoever is on call, often for the first time, and every wrong line costs minutes at the worst possible moment.

The honest problem is that nobody knows which runbooks are trustworthy. Not because the information is unavailable — because nothing collects it. Who has read this since the last rewrite? Do its links still resolve? Has the service it describes changed since?

Three of five on-call engineers have read the current version is a sentence you can only say if reading was counted against a version rather than against a document.

What it does about it

The parts that matter here

Not the whole feature list — the ones this particular problem turns on.

Read receipts you can believe

Counted after ten seconds of visible reading, never on a click in the tree, and only against the current version. Rewrite the runbook and the count resets, because the people who read the old one have not read this one.

Broken links, found before the incident

A relative link that resolves to no document is a finding, recomputed from the corpus rather than filed once and forgotten. It stops being a finding when it stops being true.

Staleness against content, not dates

Measured from the last real content change, so a file the sync worker touched for unrelated reasons does not look fresh. A newly connected repository reports no staleness at all, and the screen says so rather than implying everything is fine.

Documentation behind the code

A runbook naming a source path that changed after the runbook did is the one signal in the product that connects code to documentation — and the closest thing there is to an early warning.

Search across every service

On call for a platform means on call for services you did not write. One keystroke searches every connected repository, not the one you happen to have open.

Copy for LLM, mid-incident

Take the runbook and its neighbours to a model as clean markdown, with the token count before you paste. This is the reason people open a runbook in a second tab, and it takes one action instead of six.

In practice

What actually happens

  1. 01
    Connect the repositories the on-call rotation coversUsually several, because a rotation rarely maps to one service. They land in one project and search spans all of them.
  2. 02
    The health pass runs and finds what is already brokenBroken relative links, documents whose content has not changed in longer than your threshold, and documents naming source files that moved after they did. None of it calls a model, so none of it costs anything.
  3. 03
    Somebody dismisses the findings that are wrongA dismissal is the one durable thing here — it survives the rebuild and swallows its own re-discovery, so the same false positive does not come back every pass.
  4. 04
    The team validates the runbooks that are currentReview state on each, set against the exact text. Now trustworthy and untriaged look different from each other on the tree.
  5. 05
    A service changes and the runbook does notThe push touched a source path the runbook names. The finding appears without anybody filing it, and the validated badge reads drifted.
  6. 06
    The incident happens and the page is rightOr it is wrong in a way somebody already knew about — which is the realistic version of this promise, and the one worth paying for.
Honestly

What this does not solve

Every page on this site carries one of these, for the same reason: a use-case page with no limits on it is a brochure.

It does not verify the steps
We can tell you a link is broken and the code moved. We cannot tell you whether step four still works — nothing short of running it can.
It is not an incident tool
No alerting, no paging, no timeline, no postmortem template. It sits beside those; it does not replace them.
Staleness is a threshold you pick
There is no model deciding what old means. A runbook for something that never changes is not stale at ninety days, and only you know which those are.

Connect one repository and see it against your own documents.