Incident response
Secret exposure and production incidents - the canonical response runbooks and what to quote when reporting.
link to this sectionIncident response
Two canonical runbooks cover the operator paths:
for leaked or exposed credentials;
for deployment and rollback mechanics.
link to this sectionReporting a production failure
Standard API errors carry a body-level request_id; always include it - it ties the failure to the server-side trace. The body shape is { code, message, request_id }.
Device-flow endpoints (/auth/device/*) are the exception: their error body only has error / error_description and no request_id, so quote the X-Request-ID response header instead.
link to this sectionWhat responders will ask
- Which environment (production URL, preview, local demo)?
- The failing route and request id.
- Whether the demo stack (
pnpm demo:api) reproduces it - if yes, the
fix lands against the in-memory stack first; if not, the hosted read/write path is implicated.
- The last green
Validaterun onmain.
link to this sectionHonest status
Incident status updates state what is known and what is not. They never report availability as a percentage, and they never present a quiet system as a verified one.