Observability Platform  ·  View 05 of 25  ·  People and journeys

Journey — Observable On The Day It Ships

A new service from catalogue entry to a live SLO, without a platform-team ticket.

Editable source SVG draw.io All views
Service owner shipping a new service Goal — Be observable without a platform-team ticket Trigger — A new service registered in the catalogue Done when — Dashboards, SLO and budget live before the first production deploy 1 · Register 2 · Instrument 3 · First deploy ◆ moment of truth 4 · Add an SLO 5 · Live What they do Claims service in catalogue Adds the OTel SDK Names its log classes Ships to staging Declares indicator + target Reads the scorecard What the platform gives Owner, budget, retention class Identity from EKS Pod Identity Default dashboards generated Cardinality estimate Burn-rate rule compiled Daily cost attribution How it feels Easy Working Blocked Where it hurts Which class is this log? Rejected: user_id as a label No unsampled indicator yet What answers it Catalogue is the front door Class defaults, overridable Caught in staging, attribute named Rules refuse sampled inputs Unread data is reported Journey — Service Owner: Observable On The Day It Ships The cardinality rejection at first deploy is the design working. It is a staging event with a named attribute, not a 3 a.m. discovery from the store. v 1.0 · owner Reliability Architecture · date 2026-09

The rejection is the design working

  • The trough is a cardinality rejection at first deploy — a staging event with the offending attribute named and the owning team attached, rather than a production incident discovered from the metric store's memory pressure.
  • Moving that discovery left is the entire argument for admission at the gateway plus a pre-production estimate (views 22 and 20).

Decisions

  • The service catalogue is the front door: ownership, retention class, budget and default dashboards all derive from it, and a producer with no catalogue entry is quarantined into a low-budget default tenant rather than accepted into the general pool.
  • Log classes are declared by the emitting team, with platform defaults, because the platform cannot know which of a service's log streams is evidence and which is noise.

Risks

  • Class declaration is the step teams will skip. If most services accept the defaults unchanged, the shed order in view 18 sheds the wrong things and the storm response is worse than useless.