Authenticating...
Skip to main content

Runbooks

Operational runbooks for infrastructure and observability config — the things that aren't obvious from code alone and would otherwise get re-derived from scratch next time.

A runbook belongs here when it captures how to carry out or recover from an operation against live infrastructure. If you're documenting why we chose an approach, write an ADR instead. If you're documenting how to use a tool or library day to day, that's a guide.

Infra / SSL​

Access / Identity​

Offer sync​

  • Offer Sync: Enroll an App: giving an app its first offer sync, or moving it from batch to realtime sync, and verifying its inventory.
  • EventSync Incident Response: what each EventSync monitor means, how to confirm it, and the break-glass levers.
  • Offer Sync: Add a Per-App Metric: getting a new per-app metric from dbt into the Offer API without a one-sided key in the batch diff, using OFFER_API_IGNORED_FIELDS as the bridge and the one deploy order that works.

Elastic Beanstalk​

Cost / Observability​

Adding a runbook​

Add a Markdown file to this directory, then add it to both the list above and the Runbooks category in sidebars.ts. Include, near the top:

  • When to use this — the symptom or trigger, so someone mid-incident can tell in one read whether they're in the right document.
  • Prerequisites — accounts, profiles, and access needed, named explicitly.
  • Where the IaC lives, if the thing being operated on is managed by code.

Runbooks go stale faster than ADRs, because they describe live infrastructure rather than a decision made at a point in time. Where a fact was verified against a specific incident, ticket, or date, say so inline — that lets the next reader judge how much to trust it. Open questions are worth keeping in the document rather than dropping; a known gap is more useful than a confident-sounding guess.