The fourth phase decides how the platform lives
A platform that is built well but operated badly will decay. Certificates expire, upgrades slip, alerts become noise, and the one engineer who understood the setup leaves. The Operate phase is where we make a deliberate choice about who looks after the platform and how, so that what we built stays healthy.
There are two good outcomes: a verified handover to your own team, or managed DevOps operations run by us. Both are legitimate. The wrong outcome is the accidental third one, where nobody is quite sure who owns what.
Choosing between handover and managed operations
| Question | Leans towards handover | Leans towards managed |
|---|---|---|
| Do you have engineers who want platform ownership? | Yes | No, or too few |
| Can you staff an on-call rotation fairly? | Yes | Not sustainably |
| Is 24/7 coverage a business requirement? | Not really | Yes |
| Do you want control over every operational decision? | Yes | Prefer to delegate routine work |
| Is the platform stable and well documented? | Yes | Still maturing |
Some clients take a hybrid: they run day-to-day work and use us for out-of-hours cover, upgrades and quarterly reviews. If your team is small and the product is customer-facing around the clock, managed operations is usually safer. If you have a capable platform team, handover keeps knowledge in house, and paying for managed support would be wasteful. Our blog post what is managed DevOps covers the model in more detail.
What the Operate phase contains
Runbooks that survive contact with an incident
A runbook that has never been used is a guess. For every alert that can page someone, and every routine task such as rotating a credential or upgrading a node group, we write steps and then test them with someone who did not write them. A short runbook entry looks like this:
## Alert: HighErrorRate (checkout-api)
Severity: P2 (page during business hours, P1 if checkout is fully down)
Likely causes: bad deploy, database saturation, upstream dependency
1. Check the deploy log: was there a release in the last 30 minutes?
If yes, roll back: `argocd app rollback checkout-api`
2. Open the Grafana dashboard "checkout-api / overview".
Look at p95 latency and database connections.
3. If the database is saturated, follow runbook DB-02.
4. Post an update in the incident channel every 15 minutes.
Escalate to: platform lead, then CTO if unresolved after 1 hour.
Runbooks live in your repository or documentation system, next to the code they describe. Our SRE and incident response service goes deeper on incident process.
On-call and alert quality
On-call only works if pages are rare and meaningful. We review alerts for actionability, route by severity, and tie paging to user-facing symptoms rather than raw resource metrics. Good alerting ideas are in our Prometheus alerting rules examples, and the tooling is described under monitoring with Grafana and Prometheus.
Backups and recovery you have actually tested
We confirm backup schedules and, importantly, run a restore exercise. A backup nobody has restored is only a hope. See backup and disaster recovery for how we approach this.
Managed operations and the SLA
If you choose managed operations, the commitments are written down. Our Managed DevOps offer has cover options of business hours, extended or 24/7 depending on the plan, confirmed in the written scope. The SLA document defines:
- Severity levels with plain-language examples, so there is no argument mid-incident.
- Response targets for each severity, including P1 first response.
- What counts as in scope, and what is billed separately.
- Communication: where updates are posted and how often.
- Post-incident reviews: written, blameless, with actions and owners.
- Access model: named identities, least privilege, audited actions.
An SLA should be read like a contract, not a brochure. Ask what first response means, what is excluded, and what happens when targets are missed. Resolution times depend on the cause of an incident, so we do not promise them.
Handover: how it is verified
If you take operations in house, handover is a checklist, and each item is demonstrated, not asserted:
- Your engineers can deploy and roll back without us.
- Every paging alert has a runbook someone on your side has followed.
- Access is transferred, and our access is removed or reduced as agreed.
- Documentation covers architecture, deployment, secrets and recovery.
- A restore from backup has been performed.
- A simulated incident has been run with your on-call engineer leading.
- A named owner exists for each component.
We usually run in parallel for a period that depends on scope: first your team shadows ours, then yours leads and we support. After sign-off we remain reachable for an agreed window, so first-week questions have somewhere to go.
Quarterly reviews
Whichever model you choose, we recommend a recurring review. The agenda is practical:
- Incidents: what happened, what we changed, what keeps recurring.
- Reliability: performance against your service level objectives, where defined.
- Cost and capacity: trends and optimisation options, such as the ideas in EKS cost optimisation.
- Upgrades and risk: Kubernetes versions, provider changes, expiring components.
- Backlog: the next improvements, ranked, with owners.
The output is a short written note. If a review produces no decisions, it was not worth holding.
What we need from you
- A decision on the operating model, and a named internal owner.
- For handover: engineers available to shadow and lead, and time for the exercises.
- For managed operations: escalation contacts, a list of business-critical services, and agreed change windows.
- Honest feedback from reviews, including when the process is not working.
How to verify the quality of the Operate phase
Ask for evidence: a recent runbook that was actually used, an incident review with real actions, a tested restore, and the page count per on-call shift. Look at whether alerts are acted on or ignored. If you want to assess your starting point, try the DevOps maturity assessment, or speak to us about the right model. The cycle then returns to assessment as your needs change.