Runbooks
Every runbook follows the same shape: Symptom → Diagnosis → Fix → Prevent. Follow them top to bottom — don't skip Diagnosis or you'll fix the wrong problem.
Available runbooks
Scheduled ingestions fail, or data silently stops arriving. Usually credential expiry, rate-limit windows, or Inngest step-size limits.
Read more →Verifying mv_ad_daily_rollup (it is a VIEW; nothing rebuilds). Runs against production.
Read more →The conveyor sync model, concurrency, and registration traps.
Read more →The on-call playbook — declaration, comms, mitigation, retro.
Read more →Open exit criteria; V1 is deliberately not retired.
Read more →Backup posture, what is re-derivable, and what is not.
Read more →Provisioning the deployment-protection bypass secret so Inngest Cloud can reach the app. A manual dashboard step.
Read more →Related, outside this section: Deployment and Adding a new client.
The audit and test gates
Twelve audit:* parity gates and the test gates are defined in package.json. Run them from the repo root:
npm run audit:parity-all # the umbrella parity gate
npm run test:isolation # tenancy — must be green before any release
npm run test:mv-parity
npm run smoke:all-tenants
npm run test:all # test:unit + test:integration
Full command reference: docs.md §6.4 (repo root).
When to write a new runbook
- You've fixed the same thing twice.
- Diagnosing it the first time took more than 30 minutes.
- The fix is non-obvious from the code alone.
- Someone new to the codebase couldn't reproduce your fix from the git history.
Runbook template
Copy this into a new file under docs/docs/runbooks/, then wire it into sidebars.ts.
---
title: <One-line problem statement>
description: <Short summary — used for search + link previews>
---
# <One-line problem statement>
## Symptom
What the operator sees. Screenshots, log lines, error codes.
## Diagnosis
1. Check X → expected Y
2. If Y is wrong, check Z
## Fix
1. Ordered step
2. Ordered step
## Prevent
- Code change, lint rule, alert, or process change so this doesn't recur.