[BUG] Claude Code DevOps subagent runbook missed an 8.5-day AWS cost anomaly despite explicit daily monitoring requests — $80 burn, structural gap

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

I run a small AWS-hosted SaaS where Claude Code is my primary engineering partner. After a prior AWS cost incident, I explicitly asked the project's devops-ops-sentinel agent to perform daily anomaly scans across deployed Lambdas and infrastructure so this class of issue wouldn't recur silently. The agent was dispatched repeatedly across multiple sessions throughout May 2026.

Despite this, a DynamoDB Stream write loop on one of my tables — a small pattern-config table whose stream-consumer Lambda was writing back to the source table — ran for 8.5 consecutive days (2026-05-03 → 2026-05-11) generating:

• 47.7 million write units (~$60 in DDB writes)
• ~25 million stream events (~$5 in stream reads)
• ~8.3 million Lambda invocations (~$15 in invocations + duration)
• Total: ~$80 of preventable AWS spend

The cost-spike was a sustained ~36 writes/sec — perfectly flat, perfectly visible on CloudWatch the entire time. The Sentinel never surfaced it. The bug self-resolved on 2026-05-12 when I happened to redeploy the affected Lambda for an unrelated change.

I noticed the cost on my AWS bill ~3 weeks after the fact.

Why the Sentinel missed it (root cause)

The standard devops-ops-sentinel agent's per-invocation runbook had a robust battery of functional health checks — Lambda error rates, latency, deploy drift, telemetry-pipeline integrity, broken HTTP routes — but no cost-anomaly checks. Specifically missing:

• Per-table DynamoDB ConsumedWriteCapacityUnits scan
• Per-Lambda invocation-rate sanity check
• Cost Explorer day-over-day delta
• DDB Stream consumer write-back-to-source audit

A user who requests "anomaly checks on Lambda firing rates" reasonably expects the standard "DevOps Sentinel" agent to check exactly that. The agent's documented purpose — "proactively 3-4 times per day for routine operational health checks of deployed architecture, analytics, instrumentation, and telemetry" — does not advertise that cost is excluded from "operational health." That ambiguity is what let this slip.

Timeline (CloudWatch metrics, reproducible)

| Date | Daily writes on affected table | Daily consumer-Lambda invocations |
|---|---:|---:|
| Pre-2026-05-03 | ~0 | ~0 |
| 2026-05-03 | 3,099,988 | 1,033,328 |
| 2026-05-04 → 05-10 | ~3.1M/day each | ~1.03M/day each |
| 2026-05-11 | 933,831 (partial day) | 311,289 (partial day) |
| 2026-05-12 → today | 0 (Lambda redeployed) | 0 |

Sustained burn rate: ~36 writes/sec for 8.5 days — the hallmark of a Lambda concurrency-governed infinite loop. The bug shape: a DDB Stream consumer writing back to its source table.

Independently reproducible against any account exhibiting a similar pattern:

aws cloudwatch get-metric-statistics --namespace AWS/DynamoDB \
  --metric-name ConsumedWriteCapacityUnits \
  --dimensions Name=TableName,Value=<your-affected-table> \
  --statistics Sum --period 86400 \
  --start-time <suspect-window-start> --end-time <suspect-window-end> \
  --region <region>

What I had to build today to close the gap

After noticing the cost on my AWS bill, I had Claude Code produce a full RCA and instructed the Sentinel to:

1. Create CloudWatch alarms across every DynamoDB table in the account on ConsumedWriteCapacityUnits > 10,000 / 5min, all wired to my existing SNS topic. The May burst would have tripped these in 5 minutes.
2. Audit all my current DDB Stream consumers for the write-back-to-source pattern. All clean in my codebase post-fix.
3. Add a new always-on gotcha to my project docs capturing "DDB Stream consumers must NEVER write back to their source table." Loop-guard pattern documented.
4. Write feedback + project memories so future Claude Code sessions on this project don't re-learn this.
5. Permanently update the Sentinel's own agent definition (in .claude/agents/devops-ops-sentinel.md) so future invocations always check: per-table CWU scan flagging >1M/day, per-Lambda invocation scan flagging >100K/day, daily Cost Explorer diff, new-stream-consumer audit reminder.

This is the structural fix. It's now durable on my project — but it should be upstreamed to the shipped agent definition so the next user doesn't have to discover this gap the same way I did.

I have a full RCA (~400 lines, with daily metrics, cost breakdown, mitigations, verification commands, and a section on the process gap) on my side. Happy to share it privately if useful as a case study.

Specific product suggestions

1. Update the standard devops-ops-sentinel agent prompt shipped with Claude Code so cost-anomaly scans are first-class per-invocation items. Functional health and financial health are not the same thing; the current standard agent treats them as if they are.

1. Add a Claude Code skill or built-in tool for "AWS cost-anomaly daily diff" — a one-shot command that pulls Cost Explorer + per-service deltas. Users shouldn't have to wire this themselves to get basic cost-anomaly coverage.

1. Be more conservative in the agent's marketing description. Today it implies cost coverage ("operational health"); it doesn't deliver cost coverage. Either fix the runbook or narrow the description so users know to wire cost monitoring themselves.

1. Document in the agent description that users should additionally enable AWS Cost Anomaly Detection and AWS Budgets as bill-level guardrails complementary to the agent-side metric scans. Defense in depth — neither the agent nor AWS-native alerting alone is sufficient.

1. Consider a "post-deploy cost-impact projection" hook — when the agent (or Claude Code itself) ships a change that adds a new Lambda, a new DDB table, a new EventBridge cron, or a new DDB Stream consumer, automatically project the cost trajectory and flag if it's non-trivial. A recent feature batch I shipped added multiple new tables, streams, and crons — all of which had cost implications never raised in the design conversation.

Cost impact

Approximately $80 in unrecoverable AWS charges from the 8.5-day burst. I'll file an AWS support case for courtesy credit (the RCA quality should support the request) but full recovery is unlikely.

The bigger cost is the 9 days of debugging trust this incident burned. The Sentinel agent was the safety net I was relying on; it didn't fire.

The opportunity is for Anthropic to roll that fix back to the upstream agent definition so it ships to every Claude Code user by default.

Happy to provide the full RCA, the updated agent definition diff, the alarm-generator script, or the project memory entries privately if useful for your engineering team.

Thank you.

What Should Happen?

A user who requests "anomaly checks on Lambda firing rates" reasonably expects the standard "DevOps Sentinel" agent to check exactly that. The agent's documented purpose — "proactively 3-4 times per day for routine operational health checks of deployed architecture, analytics, instrumentation, and telemetry" — does not advertise that cost is excluded from "operational health." That ambiguity is what let this slip.

Error Messages/Logs

Steps to Reproduce

Independently reproducible against any account exhibiting a similar pattern:

aws cloudwatch get-metric-statistics --namespace AWS/DynamoDB \
  --metric-name ConsumedWriteCapacityUnits \
  --dimensions Name=TableName,Value=<your-affected-table> \
  --statistics Sum --period 86400 \
  --start-time <suspect-window-start> --end-time <suspect-window-end> \
  --region <region>

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.139

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_