A cloud cost anomaly runbook is filled in once by the cloud owner before the first alert of the providers' tools goes live, and worked through at every alert; it records which sources open an incident, who responds within which deadline, how the incident is narrowed down and contained, who is told when and which fields the post-incident review fills. The decision it records per incident: stop, throttle, watch or accept, with a person and a date. How the providers' detection works and where it is blind is explained on anomaly detection; the narrowing method with examples is the article investigate a cloud cost increase. This page is the runbook.
The template
Cost anomaly runbook <organisation>, version <1.0>, effective <date>, owner <cloud owner>
Triggers and thresholds
| Source | Threshold | Recipients | Response time |
|---|---|---|---|
AWS Cost Anomaly Detection, monitor <services or accounts> | impact from <amount> | <channel, on-call> | <4> hours |
| Azure Cost Management, anomaly alert per subscription | every alert | <channel> | <4> hours |
| Google Cloud, cost anomalies per billing account | deviation from <amount> | <channel> | <4> hours |
| Budget alert per account, subscription, project | <80> percent actual, <100> percent forecast | <team lead> | <1> working day |
| Own check: daily comparison per account and service from the export | plus <percent> against the mean of the last <7> days | <cloud owner> | <1> working day |
| Note from a team or finance | any | <channel> | <1> working day |
Severity
| Level | Extra cost per day | Response | Information |
|---|---|---|---|
| S1 | from <amount> | contain immediately, at night too | <management, finance> immediately |
| S2 | <amount> to <amount> | same working day | <team lead> same day |
| S3 | below <amount> | at the next review | review minutes |
Roles
| Role | Person | Deputy | Reached through |
|---|---|---|---|
| First response | <on-call or cloud owner> | <name> | <channel> |
| Originating team | <from tag owner or account> | <team lead> | <channel> |
| Finance | <name> | <name> | <channel> |
| Management from S1 | <name> | <name> | <channel> |
Step 1, record, within the response time
- Incident record opened: timestamp, source, scope, extra cost per day, start
- Data date checked: is the day complete, or is it a provider restatement?
- First classification: usage, price, one-off or data artefact
- Severity set per the table, information sent
Step 2, narrow down, within <1> working day
- Split in this order: account or subscription or project, service, usage type or meter or SKU, region, resource
- Resource and moment of the change identified: deployment, configuration, scaling, new job, new user
- Checked for compromise: unknown regions, services or instance types, GPU or mining patterns; on suspicion
<security runbook>first - Originating team informed with resource ids, hypothesis in the record
Step 3, contain
- Decision by
<role>: stop, throttle, watch until<date>, accept with reasoning - Reversible measure first: stop before delete, cap scaling, lower the quota, revoke the key
- For price or one-off: no technical measure; finance informed, budget line checked
- For a provider error: support case
<id>opened, credit requested
Communication
| When | Whom | What | Channel |
|---|---|---|---|
| on recording | first response, team | scope, amount per day, severity | <channel> |
| on S1 | management, finance | amount, hypothesis, next decision | <channel> |
| after containment | everyone involved | measure, expected effect from <date> | <channel> |
| after closure | review | incident record | review minutes |
Step 4, close
- Cost back at baseline confirmed: two full days in the export below
<threshold> - Total extra cost computed: amount per day times days, source named
- Credit or correction entered with the invoice number
- Alert closed in the tool, record complete
Incident record and post-incident review
| Field | Value |
|---|---|
| Id, detected on, detected by | <id>, <date>, <source> |
| Start and end | <date> to <date> |
| Scope, service, resources | <account>, <service>, <ids> |
| Kind and trigger | <usage, price, one-off, artefact>, <deployment, configuration, compromise> |
| Total extra cost and credit | <amount>, <amount, invoice number> |
| Time to detection, to containment | <hours>, <hours> |
| What would have found it earlier | <alert, budget, quota, review> |
| Measure to prevent it | <measure>, <person>, due <date> |
How to fill it in
Triggers: thresholds in amounts, not percentages, because a small account otherwise alerts every day; where the three providers' tools set their thresholds is on budget alerts and thresholds. The own check from the export catches what the tools report only days later.
Record: the second point prevents the most common false alarm, a restatement that tops up an old day (freshness, restatements and finalisation). Narrow down: the order is that of the billing data, coarse to fine; which column carries what per provider is on trends and drivers. Contain: a credit comes only with a support case and only for the provider's own errors (credits, refunds and corrections); the quota as a brake is described on guardrails and approval thresholds.
Post-incident review: the row "what would have found it earlier" is the reason for the field; the measure that follows gets a person from the RACI and goes into the next monthly review.
How to adapt it
One team: first response and originating team are the same people; the communication table shrinks to the S1 row. Several teams: the owner tag decides who takes step 2; without a tag the incident goes to the account owner.
One provider: the trigger table has three rows, tool, budget and own check. Three providers: one tool and one response time per provider, because Azure and Google Cloud deliver their data at other times, and the daily comparison runs in one currency.
Startup: two severity levels, immediate and review, and the compromise check as the first point, because a leaked key is the most expensive incident. Finance-led: finance is a recipient from S2, and every incident's extra cost appears as a row in the team's showback statement.
Sources
Read on 2026-10-21. FinOps Framework (CC BY 4.0), AWS Cost Anomaly Detection, monitors and alert subscriptions, what to do about unauthorised activity in an AWS account, analyse unexpected charges in Azure, cost anomalies in Google Cloud, budgets and budget alerts in Google Cloud.