Production readiness

The set of things a service needs before it can be run by people who will be woken up by it — as distinct from the things it needs to work. Documented here from prod-forge, which is the corpus’s first source to treat the whole list as one artifact at one-team scale.

The list, as one source draws it

Grouped by what each item answers:

• Can we tell what it is doing? Structured logs with a trace ID carried into errors, metrics (prometheus), dashboards, and health endpoints that distinguish liveness from readiness (observability).
• What happens when a dependency dies? Dependencies classified critical vs non-critical, with fallbacks per class (serve from cache, throttle), graceful degradation, and in-flight requests drained rather than dropped.
• How does a change get in, and back out? Quality gates before merge, migrations executed as part of deployment, tracked revisions, and a rollback path (dora-metrics measures exactly this half).
• What stops a mistake reaching users? Validation, sanitisation, security headers, CORS, rate limits, and a review step nobody may skip.

None of it is novel, which is the interesting part: it is the same list a large platform team would give, minus the scale.

Why it matters to a spoke about big systems

This wiki’s through-line is that the hard problem is the seams, not the components — Netflix fusing telemetry sources, the kubernetes-integration-tax‘s ~20–30 tools that must cohere, the internal-developer-platform answer of paying that cost once and productising it. production-readiness is what remains when you remove the scale: a service with a database, a cache and one deployment pipeline still has to answer every question above. The integration tax is a slope, not a threshold, and the floor under it is this list.

That also frames the IDP argument from below. A golden path is worth building when many teams would otherwise each rediscover this floor; a single team pays it directly and cannot amortise it.

The evidence problem, stated plainly

Production readiness is documented in this corpus by checklists and reference implementations, never by outcomes. prod-forge demonstrates the list on a Todo API with no incidents. The measurement frameworks the spoke already holds — service-level-objectives for the running service, dora-metrics for the pipeline — are what would turn a checklist into a claim, and nobody here has run them against one. The open question this leaves: which items on the list actually reduce incidents, and by how much?

Related

prod-forge · platform-ops · observability · site-reliability-engineering · service-level-objectives · dora-metrics · kubernetes-integration-tax · internal-developer-platform · gitops