---
title: Onboarding a new service
slug: onboarding-a-new-service
summary: The production-readiness checklist a new service passes before it takes real traffic, from repo and pipeline to monitoring, backups and on-call.
order: 24
updated: 2026-11-11
status: ready
---

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](./repo-governance-and-branch-protection.md).
- [ ] Pipeline builds once and promotes the same artifact: dev automatic, higher environments manual, [blue-green with one-click rollback](./blue-green-deploys-with-rollback.md).
- [ ] Cloud access via [OIDC](./oidc-from-ci-to-cloud.md), no static keys.
- [ ] Image scanned; no critical findings ([vulnerability response](./vulnerability-and-patch-response.md)).

### 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.

```dockerfile
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](./terraform-changes-via-merge-request.md), tagged `owner`, `service`, `env`.
- [ ] Least-privilege task or instance role ([access](./access-requests-and-least-privilege.md)).
- [ ] 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](./monitors-and-dashboards.md)); paging alerts tied to an [SLO](./slos-and-error-budgets.md).

### Data

- [ ] Backups configured and one [restore tested](./backups-and-restore-testing.md).
- [ ] Data retention defined.
- [ ] If in a compliance scope, the [change process](./change-control-in-regulated-environments.md) 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

1. Read the repo, pipeline and IaC; check each box with evidence (file path or link).
2. Produce a table: item, status (done, missing, partial), evidence or gap.
3. Draft one ticket per gap, grouped by owner.
4. 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.