Use this page when a team wants to launch a new service or containerise an old one. It is a checklist, so an agent can walk it, mark what exists, and open tickets for the gaps.
Production readiness checklist
Ownership
- Owning team, on-call rotation and escalation contact named.
- Service catalog entry: purpose, tier (critical, important, internal), dependencies, data classification.
Code and pipeline
- Repo meets the governance baseline.
- Pipeline builds once and promotes the same artifact: dev automatic, higher environments manual, blue-green with one-click rollback.
- Cloud access via OIDC, no static keys.
- Image scanned; no critical findings (vulnerability response).
Container image
- Multi-stage build; runtime image is slim or distroless, ideally well under 1 GB.
- Runs as non-root, read-only root filesystem where possible.
- Health check endpoint and graceful shutdown on SIGTERM.
- Config from environment and the secret manager, nothing baked into the image.
FROM <build-image> AS build
WORKDIR /src
COPY . .
RUN make build
FROM <slim-runtime-image>
COPY --from=build /src/out/app /app
USER 10001
EXPOSE 8080
HEALTHCHECK CMD ["/app", "healthcheck"]
ENTRYPOINT ["/app"]
Infrastructure
- All resources in IaC through MRs, tagged
owner,service,env. - Least-privilege task or instance role (access).
- Private networking; only the load balancer is public, and HTTPS only.
- Autoscaling with sane minimums (at least 2 tasks across 2 zones for anything critical).
Observability
- Structured logs with a request ID; no secrets or personal data in logs.
- Metrics: request rate, errors, latency, saturation.
- Traces if the platform supports them.
- Dashboard and monitors as code (monitors page); paging alerts tied to an SLO.
Data
- Backups configured and one restore tested.
- Data retention defined.
- If in a compliance scope, the change process applies from day one.
Operations
- Runbook: what it does, how to tell if it is healthy, top 3 failure modes and fixes, how to roll back.
- Load test at expected peak plus margin.
- Launch plan with a rollback trigger.
How an agent runs this
- Read the repo, pipeline and IaC; check each box with evidence (file path or link).
- Produce a table: item, status (done, missing, partial), evidence or gap.
- Draft one ticket per gap, grouped by owner.
- Hand the report to the service owner. Launch is their call.
Pitfalls
- "We will add monitoring after launch." You will find out about the first outage from users.
- A single task in a single zone for a critical service.
- Copying another service's IAM role because it works. It probably has far more than this service needs.