Have you ever spent time on an on-call rotation? If so, you already know the question isn’t hypothetical. Every DevOps and SRE team is being asked a similar question: Can AI replace on-call engineers, or at least make the rotation easier?
After spending several months actually running AI agents against real production incidents for our clients, here is what we observed: no, AI can’t fully replace on-call engineers today. But with the right foundations in place, it can take over most of the grunt work. In our experience, that covers about 90–95% of the investigation. The engineer still triggers the investigation, reviews what comes back, and asks the follow-up questions that help find the root cause.
Everyone talks about “the right foundations.” But what does that actually look like? Let’s break it down.
AI Can Investigate Incidents - If It Has Runbooks
The biggest factor contributing to AI incident response is whether runbooks exist for the alert that is fired.
If a proper runbook exists, an AI agent can investigate a production issue on its own by checking the dashboards the runbook points to, running the queries it specifies, correlating the signals, and finding an apparent root cause. The runbook is what gives the AI direction; it tells the AI where to look and what to check.
Without a runbook, the AI has no map. It will look through logs and metrics without a clear hypothesis, and often it won’t find the actual root cause. This is a pattern we have observed over and over: AI on-call tooling isn’t limited by the model; it’s limited by documentation.
The Cost Problem With Cloud-Hosted Agents
Before we conclude whether AI can replace on-call engineers, let’s look at how teams usually approach it first, and where it falls short.
One common approach is to run an AI agent in the cloud that automatically investigates alerts as soon as they fire. It sounds ideal: a fully autonomous system handling incidents with no human involved until there’s an answer.
In our experience, we have found that this gets expensive fast. Running an investigation through a cloud-hosted agent typically costs somewhere in the $0.50 to $1 per investigation range, and that’s before follow-up. Every additional question adds to the bill. For a business receiving many alerts each day, the costs can add up quickly. This cost increases with the number of incidents, which is not ideal for managing expenses.
A More Cost-Effective Approach: Skills + Remote MCP Servers
If cloud-hosted agents aren’t the answer to whether AI can replace on-call engineers cost-effectively, what is? We had better results by running a Claude skill or a Cursor skill directly on the engineer’s own machine instead of using a standalone cloud agent.
Here is how it works: MCP servers act as the connectors that give the AI access to your logs, metrics, and infrastructure that are deployed in the cloud and exposed securely behind a VPN. The engineer’s local Claude or Cursor instance connects to those MCP servers when an investigation starts. It can access your runbooks, code, and architecture docs to investigate the issue.
The economics here are simpler. Because the team is already paying for a Claude or Cursor subscription, there’s no separate per-investigation charge stacking on top. You are not charged for each API call for every incident; instead, you are using tools you have already paid for.
A local skill, remote MCP servers, and a VPN in between.
The Upfront Effort Behind Getting AI to Replace On-Call Engineers’ Grunt Work
None of this is free, and it is a slow process to set up. To get AI to a genuinely useful level on your on-call rotation, you need to invest in a few things first:
- Runbooks written in an organized way and clearly for an AI to follow step by step.
- An organized local file so that the skill can actually find and access your runbooks, repos, and docs without guessing.
- Thorough repository and architecture documentation. Without them, AI will have no context about how your systems are built and connected.
- MCP servers are set up securely behind a VPN, allowing the AI to access real data without exposing your infrastructure.
Teams that skip these steps and expect an AI agent to “just figure it out” against their production environment are consistently disappointed.
Why AI Can’t Fully Replace On-Call Engineers Yet
New alerts need new runbooks.
Every time a new type of alert shows up, someone has to write the runbook for it before AI can meaningfully help with that alert type.
AI needs direction to perform well.
It will be strong when guided by a clear runbook and weak when left to figure out an unfamiliar system from scratch.
Output still needs review.
AI findings are not always good enough to act on directly. There can be gaps in its reasoning.
Follow-up questions matter.
When a runbook has gaps, it’s the engineer who has to ask the right follow-up question to get to the real answer. AI output will be fine when the runbook is genuinely solid.
Someone has to start it.
In the subscription-based skill model, an engineer starts the investigation. The AI does not activate on its own to begin searching.
It’s a Journey, Not a One-Time Setup
How much AI can replace on-call engineers isn’t fixed on day one. It grows along with your runbooks. The teams that get the most out of AI tools for on-call support treat their runbooks as living documents. They regularly update these documents based on what the AI does correctly and what it gets wrong during real incidents.
As time passes, runbooks mature, and more alert types can be handled reliably by AI with less engineer involvement. Well-documented issues can be handed off to AI early in this process. Complex issues will require help from engineers’ judgment for longer. The goal is not full automation on day one; it’s steadily shrinking the amount of manual grunt work on every shift.
The Bottom Line: Two Scenarios
Scenario A — Foundations in place (runbooks, architecture docs, MCP servers deployed):
AI can handle 90-95% of investigations. The job of engineers shifts to triggering the investigation, reviewing the result, and asking follow-up questions. The grunt work moves to AI, and the judgment stays with the engineer.
Scenario B — Nothing in place (no runbooks, no MCP servers, no documentation):
AI is not providing significant help right now. The engineer is still investigating manually, just like before AI was introduced.
Where to Start: A Baseline Checklist
If you’re evaluating AI for your on-call rotation, this order is preferred:
- Write proper runbooks for your most common and high-frequency alerts first.
- Document your repositories and architecture thoroughly enough that someone unfamiliar with the system could follow it.
- Set up MCP servers and deploy them in the cloud.
- Expose those MCP servers behind a VPN securely.
- Set up a Claude or Cursor skill with access to your runbooks, repositories, and documentation.
- Refine runbooks as new alert types come in and as you find gaps in the AI’s investigation.
Get Help Building AI-Ready On-Call Infrastructure
Now you have the answer to: Can AI Replace On-Call Engineers? None of it can happen overnight, and most teams don’t have the capacity to work on this while handling their regular tasks. This is where Cloud Solitaire can help you. We help engineering teams write AI-ready runbooks, set up and secure MCP servers, and build the investigation skills that actually reduce on-call load in practice.
If you’re ready to stop debating whether AI can replace on-call engineers and start finding out how much of your own on-call grunt work it can take off your plate, book your free consultation, and our team member will walk you through where your infrastructure stands today.