Platform engineering on-call is the quiet failure mode of 2026. Gartner's much-repeated prediction was that by this year, 80 percent of software engineering organizations would run platform teams, up from roughly 45 percent in 2022. Adoption largely arrived. What did not arrive is a matching redesign of who carries the pager. Most engineering organizations bolted a platform layer onto an on-call model built for a world where every team ran its own stack, and the seams are showing every time something breaks below the product code.

The evidence is not theoretical. August 2026 has been an unusually loud month for infrastructure that other people depend on. GitHub logged more than twenty incidents in the month with a week still to run, including a near eight hour outage on 17 August that started as a capacity failure in Central US and cascaded through authentication, Actions, APIs, pull requests and Copilot. ThousandEyes counted 534 global network outage events in the single week of 17 to 23 August, with public cloud network outages rising 17 percent week over week from 162 to 189. On 21 August, Arelion, a Tier 1 transit provider, went down for one hour and 21 minutes across multiple regions at once.

None of those were caused by a product engineer shipping a bad feature. All of them landed on somebody's pager anyway. The question this post takes seriously is a boring organizational one that turns out to decide your mean time to resolution: when the failure is in the platform layer, who gets paged, who is allowed to declare, and how many hops does the alert take before it reaches somebody who can act.

The platform layer now owns most of your outages

Ten years ago the median production incident in a mid-sized company was a code change in a service, caught by a service-specific alert, routed to the team that owned the service. That model was clean because ownership boundaries matched failure boundaries. You broke it, you fixed it.

Platform engineering deliberately breaks that alignment, and mostly for good reasons. The whole point of a golden path is that product teams stop thinking about Kubernetes networking, cloud API rate limits, certificate rotation, CI runners and service mesh configuration. Those concerns move into a shared layer maintained by a smaller group of specialists. The reported payoff is real: platform teams routinely cite reductions in on-call incidents unrelated to product code, with 60 percent commonly quoted as the headline number when platform leaders make their business case to a CFO.

What August 2026 looked like from the pager

Here is the problem. Incidents did not disappear. They migrated. When the platform abstracts away the infrastructure, the infrastructure failures do not stop happening, they simply stop being legible to the teams receiving the alerts.

Consider what a typical Slack channel looked like during the GitHub disruption on 17 August. Deploys stopped. CI queues backed up. A dozen product teams saw their own dashboards go amber for reasons that had nothing to do with their services. Some of them paged. Some of them opened incidents. Several teams independently started debugging the same upstream failure, which is how you burn forty minutes of engineering time discovering something one person already knew. GitHub's own writeup afterwards noted that client retry behaviour turned recovery into a traffic spike roughly ten times normal, which is a technical failure with an organizational twin: uncoordinated humans retrying the same investigation.

Why platform incidents route badly

Three structural reasons, and they compound.

First, alerting is usually attached to services, not to dependencies. Your checkout service has an owner and a rotation. Your shared ingress controller often has neither, or has a team name in a config file that has not been reviewed since a reorg two quarters ago.

Second, platform teams are frequently smaller and newer than the surface area they cover. The 2026 Cloud-Native Developer Survey found that only 28 percent of organizations have a dedicated platform engineering team at all. The most common arrangement, at 41 percent, is multiple teams collaboratively handling platform capabilities. Collaborative ownership is a perfectly reasonable way to build a platform. It is a catastrophic way to route a page at three in the morning, because shared ownership without a named rotation is functionally no ownership.

Third, severity judgement gets harder. A product engineer woken by a failing deploy pipeline genuinely cannot tell whether this is a five minute blip, a regional cloud event, or the start of something that will consume the quarter's error budget. Without a fast way to see what else is burning, every ambiguous alert either gets escalated too aggressively or sat on too long.

Platform engineering on-call: the ownership gap in the data

The numbers around platform maturity are worth sitting with, because they explain why so many organizations have a platform and still have chaotic incident response.

Adoption is high, structure is thin

Adoption sits somewhere above half of organizations by most counts, and the Gartner 80 percent figure for large software engineering organizations is now roughly where reality landed. But the 2026 Cloud-Native Developer Survey data shows the structural picture is far less mature than the adoption headline suggests. Fewer than three in ten organizations have a dedicated team. That gap between "we do platform engineering" and "there is a specific group of people accountable for the platform being up" is exactly where on-call ownership goes missing.

The State of Platform Engineering Volume 4 data reinforces it from a different angle. The top reported challenges are cultural, not technical: 45.3 percent cite driving developer adoption, 44.3 percent cite lack of a shared vision or product mindset, and 43.9 percent cite complexity in existing systems. Technical complexity ranks third. Platform engineering is a sociotechnical problem, and on-call ownership is the most operationally sharp expression of that.

The measurement blind spot

The same research found that nearly 30 percent of platform teams do not measure success at all, an improvement on the prior year's 45 percent but still a large hole. Of those that do measure, 40.8 percent use DORA metrics, which include time to restore service.

Here is the uncomfortable implication. If your platform team does not measure time to restore for platform-layer incidents specifically, you cannot tell whether your platform is improving reliability or just relocating the pain. Product teams will report fewer infrastructure pages, which looks like a win, while overall organizational MTTR quietly gets worse because the pages that do happen now take three hops to reach the right person.

Separately, InfoQ's coverage of Perforce's 2026 State of DevOps research found that 73 percent of organizations with mature platform practices said platform maturity was a critical or significant factor in their AI success, compared with 44 percent among less mature organizations. Maturity is doing a lot of work in that sentence, and operational maturity, meaning you can detect and route and resolve platform failures reliably, is a large part of it.

Four ownership models, and where each one breaks

There is no universally correct answer here, but there are four common patterns and each has a specific failure mode worth knowing before you pick.

Model 1: the platform team carries everything infrastructure

Every alert originating below the application layer routes to a single platform rotation. Clean, easy to explain, and the fastest to implement.

It breaks on volume and on depth. A platform rotation of four or five engineers covering CI, cloud accounts, networking, observability, secrets and the deploy system will drown. It also creates a knowledge asymmetry: the platform on-call receives a page about a product team's service degrading due to a platform issue, but cannot assess business impact or make the call on user-facing mitigation. This model works well below roughly 150 engineers and gets fragile fast above that.

Model 2: product teams carry everything, platform is business hours

The platform team behaves like an internal vendor with a support queue. Product teams stay on the hook for anything affecting their service, including infrastructure causes.

It breaks on capability. You are asking an engineer who has deliberately been abstracted away from Kubernetes to debug Kubernetes at 2am. The platform's entire value proposition is that they no longer need that knowledge. This model reliably produces long incidents and quiet resentment, and it is the single most common cause of "our platform team is unpopular" complaints.

Model 3: split by layer with a named platform rotation

This is the sensible default for most organizations above about 100 engineers. Product teams own service-level alerts and business impact. The platform team owns a real 24/7 rotation for shared infrastructure. Crucially, both can be in the same incident at the same time, with the product on-call owning customer communication and the platform on-call owning technical mitigation.

It breaks on handoff quality. The failure mode is the platform engineer fixing the underlying issue and closing the incident while the product team is still degraded, or the product team declaring resolved while the platform is still fragile. This is fixable with process, which is why it is the model most large organizations converge on.

Model 4: embedded platform liaison

A platform engineer rotates through product teams, or each product team has a designated platform-literate engineer who becomes first responder for infrastructure-adjacent alerts.

It breaks on scale and on fairness. It works beautifully for a handful of critical teams and becomes impossible to staff across twenty. Treat it as a supplement to Model 3 for your highest-criticality services, not as your primary structure.

How to design platform on-call that actually works

Whichever model you choose, the same handful of mechanics separate teams that recover quickly from teams that flail.

Write the boundary down as a routing rule, not a wiki page

Ownership documented in Confluence is ownership that does not exist during an incident. The boundary between platform and product needs to be encoded where alerts are actually routed: in your alert rules, your service catalog and your escalation policies. If you cannot answer "who does this alert page" by reading configuration rather than asking a person, you do not have an ownership model, you have an aspiration.

A practical test: pick three shared components at random, your ingress, your secrets manager, your CI runners, and trace each one from alert to human. If any of the three ends in a channel with no rotation attached, you have found a gap that will cost you an hour during the next real incident.

Give the platform team its own error budget and its own SLOs

Platform teams that are measured only on developer satisfaction survey scores will optimize for features over reliability, because that is what they are graded on. Platform SLOs should be stated in terms product teams care about: deploy pipeline availability, time from merge to deployable artifact, control plane API success rate. When the platform burns its budget, feature work on the platform stops. This is the same discipline product teams have accepted for a decade and it is routinely absent from platform teams.

Make escalation one hop, and make it visible

The most expensive minutes in a platform-layer incident are the ones spent finding the right person. A product on-call who suspects an infrastructure cause should be able to pull the platform on-call into the existing conversation without opening a ticket, without knowing a name, and without switching tools. Every additional hop adds minutes and adds the risk that the escalation quietly dies in a channel nobody is watching.

Separate detection from diagnosis in your alert design

Product-level alerts should detect user impact. Platform-level alerts should detect platform health. When you conflate the two, product teams get paged for platform symptoms and the platform team finds out about its own outage from a customer complaint. Both layers need independent signals, and the incident channel is where they get correlated by humans.

Concretely, the practices that consistently reduce time to resolution for platform-layer incidents are:

A named 24/7 platform rotation with real coverage, not a shared inbox or a best-effort channel. Shared ownership without a rotation is no ownership.
Dependency-aware routing so that a failure in a shared component pages the component's owner directly, rather than fanning out to every downstream consumer at once.
A single incident channel per incident, with both product and platform responders present, so that six teams debugging the same upstream failure collapses into one investigation.
An explicit declare-and-defer rule: any responder can declare, and the first question in the channel is always whether this is upstream, so nobody spends thirty minutes debugging their own service during a provider outage.
Platform SLOs with a real error budget that gates platform feature work, reviewed monthly alongside product SLOs.
Handoff criteria for resolution, so an incident closes only when both the platform cause is mitigated and the product-level impact has recovered.
Postmortems that name the ownership failure, not just the technical one. If routing added twenty minutes, that belongs in the timeline as a contributing factor.

Why Slack is the right surface for platform on-call

There is a practical reason platform ownership problems get solved in chat rather than in a dedicated incident tool, and it is not fashion. Platform incidents are cross-team by definition. They involve people who do not share a service, a dashboard or a vocabulary. The only place all of them already are, at 3am, on a phone, is Slack.

This is where a Slack-native approach earns its keep. When on-call schedules live in Slack as user groups that stay in sync with the rotation, a product engineer who suspects a platform cause can pull in the current platform on-call by mentioning a group, without knowing who is on shift and without leaving the channel where the investigation is already happening. That removes a hop. Across a year of incidents, removing a hop is worth more than most tooling upgrades.

It matters for the reverse direction too. Platform teams need a fast way to broadcast "this is us, we know, stand down" to every affected product team simultaneously. Six teams independently debugging a shared failure is the organizational version of a retry storm, and the fix is the same: coordinate rather than amplify.

Pagerly was built around exactly this shape of problem: rotations, paging, escalation and incident channels running inside Slack and Microsoft Teams, syncing with the schedules and ticketing systems teams already run. The point is not to add a tool but to remove the context switch at the moment it is most expensive.

A 30 day plan to close the platform on-call gap

If the sections above described your organization, here is a sequence that produces measurable improvement within a month without a reorg.

Week one: inventory. List every shared component that could take down more than one product team. For most organizations this is between eight and twenty things: CI, artifact registry, ingress, service mesh, secrets, observability pipeline, deploy tooling, shared databases, DNS, identity. For each one, record the current alert destination and whether a human rotation is attached.

Week two: assign and route. Every item on that list gets a named owning team and an escalation policy. Where the owner is genuinely shared, pick one team as the paging destination and document the others as secondary. Ambiguity resolved arbitrarily beats ambiguity preserved carefully.

Week three: rehearse. Run a game day on a platform-layer failure. Take out the deploy pipeline in a staging environment during working hours and watch what happens. The thing you are measuring is not the technical fix, it is the number of minutes between first alert and the right person being in the right channel. Most teams are surprised by this number.

Week four: instrument. Start tracking time to restore separately for platform-layer incidents. Add a simple tag at declaration time. Within a quarter you will have the data to tell whether the platform is reducing organizational incident load or redistributing it, which is the question the 30 percent of platform teams who measure nothing cannot answer.

The takeaway

Platform engineering delivered on a lot of its promise. Developers ship faster, cognitive load on product teams genuinely dropped, and the golden path is real in a way it was not three years ago. But abstraction moves failure, it does not eliminate it, and August 2026 was a useful reminder that the layer beneath your application is failing often enough to matter.

The organizations handling this well are not the ones with the most sophisticated platform. They are the ones where any engineer can answer three questions instantly: who owns this component, who is on call for it right now, and how do I get them into this conversation. Those questions are cheap to answer and expensive to leave unanswered. If your platform on-call model cannot answer them today, that is the highest-leverage reliability work available to you this quarter, and it costs a spreadsheet and four weeks rather than a migration.