A checkout API starts timing out at 3 AM.
The developer says: "The Kubernetes cluster is broken."
The platform engineer says: "All the nodes are Ready. Your application is broken."
The customer doesn't care which team is right.
If your incident process begins with arguing over ownership, your ownership model isn't finished.
"You build it, you run it" is a principle, not a complete runbook
Application developers should understand the behavior of the software they ship. They need useful logs, metrics, deployment visibility, and responsibility for application failure modes.
That does not automatically make every developer responsible for CNI configuration, node pools, API server availability, ingress infrastructure, or etcd recovery.
A good platform team provides reliable, documented infrastructure and an understandable operating interface. A good application team owns the behavior of its service on that platform. Real incidents frequently involve both.
Design on-call around symptoms and expertise
I'd separate responsibilities into three layers:
| Layer | Primary ownership | Example |
|---|---|---|
| User-facing service | Application team | Elevated checkout error rate after a release |
| Shared platform | Platform/SRE team | Cluster-wide DNS failures or node capacity exhaustion |
| Incident coordination | Named incident commander | Cross-team outage requiring decisions and communication |
The initial page should reach a team capable of making progress, not merely the owner of a particular tool. Use escalation paths when the cause crosses boundaries.
The alerts that create blame
"Pod restarted" often reaches the wrong people. One restarted pod may be harmless; a failing customer transaction is not.
Route symptoms by customer impact and probable action. Link each page to a runbook with dashboards and clear escalation contacts. If a page lands with someone who cannot diagnose or mitigate it, fix the alert routing rather than blaming the person.
Run one exercise before the next incident
Pick a plausible scenario: CoreDNS becomes unreachable, the API has a latent dependency problem, or a new release increases errors. Have the teams walk through who receives the first alert, who declares an incident, what each team checks, and who can roll back or mitigate.
Write down points where the process stalls because nobody owns the decision.
On-call responsibility should reflect control, expertise, and the ability to act, not a slogan printed on an engineering slide.
Discussion: When an application fails on Kubernetes, who should be paged first—and what decides that in your company?
If your platform needs clearer ownership, incident-ready observability, or operational runbooks, explore Kubernetes consulting or request a free discovery call.