Proactive and schedule-driven; strictly read-only and alert-only.
Step 0 — Orient and resume
Read the durable ledger first — the current per-service/per-account baseline,
the last date it was updated, prior anomalies and how they resolved, and any
noted seasonal or planned patterns to exclude:
.singulacomp/memory/cloud-cost-baseline.md
This is a reuse session re-prompted daily, not a fresh session — the baseline
is cumulative. If the ledger doesn't exist yet, this is the first run: build
the baseline from as much Cost Explorer history as is available (up to 90
days) before flagging anything, and note in the ledger that day one is a
baseline-only run with no alerts.
Step 1 — Pull the prior day's spend (read-only)
Query AWS Cost Explorer, read-only, for the most recently closed day (Cost
Explorer data typically settles ~24h behind), grouped by:
- Service (e.g. EC2, RDS, S3, Lambda, data transfer)
- Linked account (for multi-account setups)
Pull both the cost amount and, where available, the usage quantity (so a
price-driven versus usage-driven change can be told apart later).
Step 2 — Update the baseline
For every service/account pair seen, fold the new data point into its running
baseline (trailing mean and spread over the last ~30 days is a reasonable
default absent a memory override). A pair with no history yet gets one day of
baseline and is not eligible for an anomaly check until it has enough history
to have a meaningful "normal."
Step 3 — Detect spend that breaks the baseline
Compare each service/account's new data point against its own updated
baseline — never a flat, cross-service dollar threshold. Flag a pair as
anomalous when it clears {{anomaly_threshold_pct}}% above its own baseline
(or a tighter/looser bound noted in the ledger for that specific pair).
| Signal | Read as |
|---|
| Spend within {{anomaly_threshold_pct}}% of baseline | Normal — no alert |
| Spend above threshold, one account, one service | Isolated anomaly |
| Spend above threshold, same service across multiple accounts | Possible platform-wide cause (price change, shared config) |
| Spend above threshold, matches a noted seasonal/planned pattern in the ledger | Suppress — do not alert |
Step 4 — Attribute the likely driver
For each anomaly, look at what changed underneath the number before writing
the alert:
- New resource — a resource ID that first appears in the window's
resource-level detail (new instance, new volume, new function).
- Traffic surge — usage quantity (requests, GB transferred, invocations)
scaled with the cost, on resources that already existed.
- Region shift — spend appearing in a region with no or minimal prior
history for that account.
- Price/rate change — cost rose but usage quantity did not, or rose much
less proportionally.
State the driver as a best guess with the evidence, not a certainty — e.g.
"cost is up 62% vs. baseline; usage (requests) is up 58% over the same window
— looks like a traffic surge, not a new resource."
Step 5 — Post the alert
Post one Slack message per anomaly to {{alert_channel}} (or one message
covering all of the day's anomalies if there is more than one — never zero
messages folded into a "nothing to report" post; if nothing is anomalous,
post nothing). Each anomaly line carries: the service, the account, the delta
(dollar and percent vs. baseline), and the suspected driver with its
evidence. Never write to AWS — the Slack post is the only output.
Step 6 — Update the ledger
Update .singulacomp/memory/cloud-cost-baseline.md (see <ledger-format>) with
the refreshed baseline, any anomalies alerted today, and any new
seasonal/planned pattern a human has since confirmed. Land a scoped
memory: cloud-cost-baseline change request for the ledger update only, after
the Slack alert (or no-alert) has been posted.