Skip to main content
The playbooks live in docs/operations/ in the repository. They are intentionally short — five to ten minutes of reading, not exhaustive treatment — and each is self-contained.

​
When to reach for which

​
The three you will reach for under pressure

A bad release in production. Redeploy the previous image; treat database migrations as forward-only — rolling one back is a restore, not a redeploy, which is why the rollback and restore playbooks are separate documents.
Site down, sign-in broken, or a degraded dependency. Covers triage order, what to check first, and how to communicate.
The runbook does not currently cover the nDSG breach-assessment and EDÖB notification decision. For an incident with a suspected data exposure, escalate to the controller’s data-protection contact alongside the technical response — the playbook will not prompt you.
Point-in-time restore of PostgreSQL, and what to do about blob storage and Key Vault alongside it. A database restored without its matching documents is half a restore.

​
Secret rotation

Three secrets have their own playbooks because rotating them naively logs people out, breaks the mailbox, or gets silently reverted by the next deploy:
  • Magic-link secret — rotating it invalidates every outstanding link, including onboarding links valid for seven days. The playbook covers the overlap window.
  • Graph client secret — expiry shows up as the mailbox reporting auth-expired in the messages surface. The mailbox diagnostic identifies it; the playbook rotates it.
  • M365 SSO client secret — expiry shows up as AADSTS7000222 on the login page and blocks every M365 sign-in. The deploy workflows overwrite the App Service value from a GitHub environment secret, so the rotation must update both — the playbook covers that trap.
Database credentials rotate on a schedule through a dedicated workflow.

​
Customer onboarding

Standing up a new installation: Azure resources, Entra registration, the shared mailbox, branding, seed data, feature flags, the first administrator, and the customer-side IT contact. The checklist ends with a verification section — as they all do.

​
Customer overlays

The playbooks are customer-agnostic and use placeholders (<app>, <rg>, <vault>). What specifically exists in a given customer’s environment — the resource inventory, contacts, decision log — lives under docs/customers/<customer>/. Keep the two apart. A playbook with one customer’s resource names in it is a playbook that cannot be used for the next customer.

​
Ownership

Each installation has a primary on-call — the platform maintainer — and a customer-side IT contact for M365 and Azure billing, recorded during onboarding.
Update the relevant playbook in the same PR as any production change that affects operations. A stale playbook is worse than a missing one, because it is trusted at 03:00.