At 3:17 AM last Tuesday, my payment-api ECS service entered a terminal failure loop. 7,279 failed tasks since August 13th. The health check expected /api/health but the container only served static content. Every 60 seconds, ECS killed the task and replaced it. Burning compute the entire time.
No alarm fired. I never set one up. No PagerDuty page. No Slack alert. Just a service churning through resources that nobody was watching.
Not because I got lucky. Because my Kiro Crew agent was awake. It spawned 5 parallel investigations, called AWS DevOps Agent for a health assessment, found the root cause across ECS, CodeBuild, CodePipeline, and Lambda, and flagged everything with severity-prioritized fixes. By 3:24 AM, done.
This is Part 6 of my Kiro Crew series. Parts 1 to 5 showed what Crew can do: orchestrate agents, run cron jobs, enforce security, build custom apps. This one shows what happens when you connect it to AWS's production intelligence engine.
Table of Contents The problem nobody talks about What AWS DevOps Agent actually is The integration: one MCP config block The architecture Live demo: what the agent found Applying the fixes The cron job: check every 30 minutes The investigate skill: deep root-cause analysis The security model: why this is safe The self-learning layer 34 tools at your agent's fingertips Cost considerations Try it yourself (complete walkthrough)
Every DevOps team I've worked with has the same gap: the space between "something went wrong" and "someone noticed."
PagerDuty fires when alarms trigger. But what about the things you never set alarms for? The ECS service silently cycling through failed tasks for four days straight. The CodeBuild project that's been FAILED since last week with nobody looking at it. The Lambda with a 3-second timeout calling a service that needs 6 seconds to respond.
These aren't incidents. They're slow leaks. And they only become incidents when a customer complains or the bill arrives.
I've seen this pattern across a dozen client engagements. The monitoring is always incomplete. The alarms cover the obvious cases. The subtle failures accumulate silently until something visible breaks.
Here's what incident response looks like at most organizations I've consulted for:
| Step | Who | Time | Problem | |---|---|---|---| | Alert fires | PagerDuty/OpsGenie | 0 min | Only works if alarm exists | | Engineer wakes up | On-call human | 5-15 min | Context switch, fatigue, stress | | Login to console | Human | 5 min | MFA, VPN, finding the right account | | Check CloudWatch | Human | 10 min | Which metrics? Which log group? Which time window? | | Correlate signals | Human | 15-30 min | Was there a deployment? Config change? Upstream issue? | | Identify root cause | Human | 15-60 min | Experience-dependent, often wrong first guess | | Write fix | Human | 10-30 min | Under pressure, at 3 AM, with fatigue | | Apply + verify | Human | 10 min | Hope it doesn't make things worse | | Total MTTR | | 1-3 hours | And that's IF an alarm existed |
The real killer: if no alarm was configured, this entire process never starts. The failure just accumulates until someone notices manually.
| Step | Who | Time | Difference | |---|---|---|---| | Cron fires (every 30 min) | Kiro Crew | 0 min | No alarm needed, proactive scanning | | Check all services | Crew + DevOps Agent | 30 sec | Parallel, covers everything | | Correlate signals | DevOps Agent | 60-90 sec | X-Ray, CloudWatch, deployments, topology | | Identify root cause | DevOps Agent | 2-3 min | Consistent, no fatigue, no wrong guesses | | Generate mitigation plan | DevOps Agent | 90 sec | Exact CLI commands, rollback steps included | | Apply fixes | Kiro Crew | 30 sec | Or: open PR for human review | | Verify healthy | Kiro Crew | 30 sec | Automated validation | | Total MTTR | | 5-7 minutes | No human woken up |
AWS designed DevOps Agent as a read-only investigator. It observes, correlates, and produces mitigation plans with exact commands. But it never executes anything. That's intentional (security: no prompt injection risk from write operations).
Kiro Crew fills that gap. It takes DevOps Agent's mitigation plan and executes it (or opens a PR for human approval in production).
The separation: DevOps Agent = the brain (read-only, investigates, produces exact fix commands) Kiro Crew = the hands (orchestrates, executes, verifies, learns from past incidents)
Neither alone solves the problem. Together: autonomous incident response that runs 24/7, catches issues before customers notice, and gets smarter with every incident.
What enterprises gain No more silent failures. Cron catches issues whether or not alarms exist. Consistent investigation quality. DevOps Agent doesn't get tired at 3 AM or skip steps under pressure. 75% lower MTTR. AWS reports 75% reduction in customers using DevOps Agent. Adding Crew automation pushes it further. Institutional memory. Crew's Knowledge base remembers every past incident. New team members inherit years of operational wisdom. Audit trail by default. Every investigation, every fix, every decision logged in CloudTrail and Crew sessions. Human-in-the-loop when you want it. Trust mode for non-critical environments, PR approval for production.