DevOps Guru Shuts Its Door Thursday: Your Exit Plan

Your ML watcher just got an end date, and the clock starts this Thursday.

AWS DevOps Guru stops taking new customers this Thursday, October 29, 2026. Nothing switches off that day. Support ends September 30, 2027. AWS points people to Amazon CloudWatch and the Amazon DevOps Agent.

What Guru actually did

Guru was an ML watcher that flagged odd behavior without hand-set thresholds — and for a small team, that was the whole point: nobody had time to tune hundreds of alarms. It raised insights; who got woken by them was your wiring, not its.

What replaces it

Amazon CloudWatch already has the building blocks, but you wire them up yourself.

Amazon DevOps Agent is the newer path: an AI agent, not a passive detector. I build and direct agents, and I only trust one after I know what it can see and touch.

Guru was a smoke alarm. The replacement is a smoke alarm plus a helper that can go look at the fire.

The 3AM shift still needs a watcher. You just have to build this one on purpose.

Before Thursday: Can You Hand This Migration to an Agent?

This is the first job I'd give an agent: wide, dull, and easy to lose track of. Start with inventory. Point it at your account and have it list every Guru resource group, what defines it, and what sits inside.

Then the mapping. For each signal Guru watched, the agent proposes a CloudWatch alarm, an anomaly detector, or "no clean match, a human decides." It writes the result as a table in version control, unmatched rows on top. Now the migration is a diff you review line by line.

Then the trial. Run the new alarms beside today's alerts and have the agent log every time one fires and the other stays quiet. A person decides whether each mismatch is a gap or noise.

Where the agent gets it wrong.

• Wrong signal, right name. It maps a detector to an alarm that sounds like the same thing but watches a different metric, and it tells you so with total confidence.
• Silent gaps. A resource group never gets re-created, nothing errors out, and nobody notices the hole until the night something breaks inside it, because a missing row makes no noise.
• "All covered" on half a list. The inventory got cut off partway through, and the summary at the bottom still says every group is mapped.
• Permission creep. It asks for broad access so it can "just handle it," and each request sounds reasonable on its own until you add them up.
• Old insights as gospel. It treats what Guru flagged months ago as the truth about your system, even though the stacks, the traffic, and the owners have changed since then.

So the human sets the guardrails: read-only access for the inventory, a group count you pull yourself to check the agent's, and a person signing off before any alarm is created or deleted. The agent hands over evidence, not a verdict.

Five steps to start now

Each step is small.

• Take inventory. List every Guru resource group you have, whether it's based on CloudFormation stacks or tags. Write down what each one covers and who owns it.
• Map each detector to CloudWatch. For every service Guru watched, decide which CloudWatch alarm or anomaly detector covers the same signal. Note any gaps where Guru caught things you never set up alarms for.
• Trial the DevOps Agent on one service. Pick one service. Not your most critical one, and not a toy. Run the agent next to your existing alerts and compare what each one finds.
• Export open recommendations. Pull your current insights and recommendations out of Guru and save them somewhere you control. Do it well before the deadline, not the week of.
• Put September 30, 2027 on the calendar. Set a reminder a few months ahead, with a named owner. Dates that live in nobody's calendar don't get met.

Retiring a watcher isn't a crisis. It's a chance to ask what you were really relying on, and whether anyone actually knew.

When Guru goes, which signal do you think you'll miss most, and do you know today which alarm covers it?

---

Disclaimer

• This post describes my personal experience with my own systems and accounts, in my own words. It is a first-person account of what I observed and what I do in my own work — not a statement of any company’s intentions, policies, or internal decisions. Where I do not know something, the post says so.
• I am not affiliated with, endorsed by, or speaking for any company, product, or vendor named in this post. All product and company names are trademarks of their respective owners and are mentioned only to describe the experience accurately.
• Any error messages, documentation excerpts, or figures quoted here are reproduced from my own records or from the public sources linked in the post, believed accurate at the time of writing. Product behavior changes over time; verify against current official documentation before relying on any detail.
• Nothing in this post is professional, financial, legal, or security advice for your specific situation. Examples are illustrative — validate in your own environment before running anything in production.
• Corrections are welcome. If any company named here publishes an official statement, or if any detail is wrong, I will update this post and note the correction. The goal is an accurate public record, not a verdict.

---

© 2026 Honey Kiran. All rights reserved.

Honey Kiran · DevOps & Platform Engineering

AI agents transforming DevOps, infra, platform, security & SRE. The shift nobody works anymore: deep dives, 3AM Files, and OpsBites.

Examples are illustrative — validate in your own environment before running in production.