Skip to main content

Monitoring & observability

The instrumentation baseline every build ships with — so "operable" is checked at the Production Readiness gate, not hoped for. Observability starts in Build, not after an incident.

The baseline​

  • Golden signals — latency, traffic, errors, saturation — on every service.
  • SLOs with error budgets — targets that make reliability a decision, not a vibe.
  • Structured logging + tracing via OpenTelemetry — correlate across services; no secrets/PII in logs (secrets management).
  • Standard alert routing — alerts go somewhere accountable, tied to runbooks.

Why it's a Build standard​

Retrofitting observability after launch means flying blind through the first incidents. Shipping it with the code — as part of the scaffold and the Definition of Done — means every RAPID product is diagnosable from day one, and the runbooks that Support inherits actually point at real dashboards.

Standards referenced: Google SRE (golden signals), OpenTelemetry.