Disaster Recovery (DR) has traditionally been the “eat your vegetables” of IT operations: universally acknowledged as vital, but often neglected until a crisis forces the issue. In the pre-agentic era, DR testing was a high-stakes, high-effort event—a “Game Day” that required weeks of coordination, executive sign-off, and often a weekend of anxious monitoring. The result? Most organizations test their full DR plans annually at best. Between these rare tests, infrastructure drifts, configurations change, and the “tested” recovery plan slowly decays into fiction. ...

When Netflix introduced Chaos Monkey over a decade ago, the premise was radically simple: randomly terminate instances in production to force engineers to build resilient systems. It was blunt, effective, and terrified everyone who wasn’t Netflix. Over time, chaos engineering matured. We moved from random destruction to controlled experiments. Tools like Gremlin, Chaos Mesh, and LitmusChaos allowed SREs to precisely target blast radiuses—injecting latency into a specific microservice or dropping packets between two zones. But even with these tools, chaos engineering remained a high-friction activity. It required an SRE to hypothesize a failure mode, write the experiment code, schedule a “game day,” run it manually, and analyse the results. ...

In traditional operations, security and reliability often find themselves at odds. The SRE team wants to ship features and maintain uptime; the security team wants to lock everything down, often slowing velocity. But in the world of Agentic SRE, this distinction is collapsing. Security is reliability. A breach is just a different kind of outage—one with potentially higher stakes. As we move into 2026, the mandate for SREs is expanding. It’s no longer enough to keep the site up; we must keep it safe. And just as we use agents to manage capacity and incidents, we must now deploy agents to manage safety and security. ...

This is Day 6 of our series “Agentic SRE: When AI Takes the Pager”. We’re exploring how AI agents are rewriting the rules of reliability, one domain at a time. “Don’t deploy on Friday.” It’s the oldest rule in the book. Why? Because historically, change is the single biggest predictor of instability. Google’s data suggests that roughly 70% of outages begin with a binary or configuration change [1]. For two decades, we’ve fought this with better testing, CI/CD pipelines, and rigorous code reviews. But the fundamental problem remained: we were pushing code faster than we could verify its safety. ...

For two decades, the “pager” has been the defining artifact of the Site Reliability Engineer’s life. It is a symbol of responsibility, a source of burnout, and the ultimate interrupt. When the pager goes off, a human drops everything to decipher cryptic logs, correlate dashboards, and frantically type commands to stop the bleeding. In 2026, the pager still goes off—but increasingly, it’s an AI agent that answers. Welcome to Day 5 of our Agentic SRE series. Today, we explore the most high-stakes domain of agentic operations: Autonomous Incident Response. We are moving beyond “AIOps” tools that merely cluster alerts or highlight anomalies. We are entering the era of agents that triage, diagnose, mitigate, and resolve incidents with minimal human intervention. ...

When we talk about “Agentic SRE,” we often focus on the what—what the agent can do, what models it uses, or what access it has. But in 2026, the critical architectural decision is actually the where. Does your SRE agent live inside your cluster, running as a Kubernetes operator with direct access to the control plane? Or does it live in a SaaS vendor’s cloud, ingesting telemetry and sending commands back over an API? ...

Site Reliability Engineering (SRE) has always been about automation. From the earliest shell scripts to complex Kubernetes operators, the goal has been to eliminate toil. But until recently, automation was largely deterministic: if X happens, do Y. The human engineer was the control plane, deciding which automation to run and when. In 2026, we are witnessing a fundamental inversion of this model. We are moving from AI-assisted SRE—where tools suggest actions to humans—to Agentic SRE, where autonomous agents observe, reason, decide, and act in closed loops, with humans moving to a supervisory role. ...

In 2003, a Google engineer named Ben Treynor Sloss was handed a team of seven software engineers and told to keep Google’s production systems running. His approach — treating operations as a software engineering problem — would eventually reshape an entire industry. But in the two decades that followed, the world changed beneath our feet: monoliths shattered into microservices, on-prem servers migrated to ephemeral cloud infrastructure, and the sheer complexity of modern distributed systems outpaced any human team’s ability to reason about them in real time. Now, we are entering a new era where AI agents don’t just assist operations; they drive them. ...

If you ask five engineers to define Site Reliability Engineering (SRE), you will get five different answers. For some, it is simply “operations with a software mindset.” For others, it is strictly about error budgets and Service Level Objectives (SLOs). And for a growing number in 2026, it is the discipline of managing the AI agents that manage the systems. But before we can discuss Agentic SRE—the automation of reliability work by autonomous AI—we must agree on what work is actually being done. You cannot automate what you do not understand. ...

Over the last 10 days, we’ve built something incredible. We started with a Raspberry Pi, gave it a brain (Gemini/OpenAI), eyes (Vision), a voice (TTS), and even a job (writing this blog). But there’s a catch. We’ve built a highly capable autonomous agent with shell access, internet connectivity, and the ability to execute code. If that sounds like a security risk, you’re right. Today, we’re locking it down. We’re not just securing the Raspberry Pi; we’re teaching the agent to audit its own security using a specialized Healthcheck Skill. ...