Review daily cost spikes for a cloud account, record what each one meant, and ask CloudThinker to find the cause
A cost anomaly is a day when one service cost noticeably more than its recent normal, based on finalized billing data. Optimize → Anomalies lists them for one cloud account so you can confirm each spike, record what it meant, and hand the cause analysis to CloudThinker.
At least 14 days of finalized daily billing history for each service. Until then, the page shows Baseline preparing and a count of finalized days, instead of claiming there are no anomalies. A service you start using later also needs its own 14 days before it can be flagged, even on an older account.
Workspace role Developer or higher to review or investigate. Viewers can read the list and evidence. See Roles.
Optimize compares each service’s daily cost with the median of the previous 14 days. It scores the day by how far it sits above that median, measured in scaled median absolute deviations (MAD). A day is flagged only when both gates pass:
Unusual: the score is above 3.5.
Large enough: the increase is at least 20 or 15% of the baseline, whichever is higher.
Only increases are flagged. To spot a drop that could mean an outage or a broken workload, compare months in Cost Explorer or ask CloudThinker about the service.Severity comes from the size of the increase and the score:
Severity
Rule
High
Increase above 500, or score above 6
Medium
Increase above 100, or score above 4.5
Low
Anything else that passed detection
The amounts (20, 100, 500) are plain numbers in the account’s billing currency and aren’t converted from USD. On an Azure scope billed in a currency such as JPY or VND, they’re small, so the 15% gate does most of the filtering and more anomalies come out as Medium or High.
The numbers on an anomaly (actual cost, baseline, estimated impact, severity) always come from saved billing data, never from an agent’s judgment. Billing data arrives late, so this is a daily review tool, not real-time alerting.
In the sidebar, select Optimize → Anomalies and pick the cloud account in the page header.Success state: summary cards show the Needs review count, total Estimated impact, and High priority count for the range.
Anomalies for an AWS account with no open anomalies in the last 30 days
2
Pick the window
Choose 30 days or 90 days. Use the tabs (All, Needs review, Investigating, Reviewed, Retracted) and the Severity and Disposition filters to narrow the list.The Needs review tab means nobody has recorded what this spike meant yet. It is unrelated to the Needs reviewfinding class on Findings.
3
Open the evidence
Select an anomaly. The detail panel shows:
Field
Meaning
Actual cost
What the service cost on the flagged days
Rolling baseline
The 14-day median it was compared with
Estimated impact
Actual cost minus baseline. Not a savings estimate or invoice credit.
The last finalized billing date the detection used
Top contributors
The regions that made up most of the cost. Regions only: for resources or usage types, use Investigate with CloudThinker
A chart plots actual daily cost against the baseline and the Expected upper bound.
4
Check the linked findings
If an agent has tied the spike to a savings finding, an Explained by list appears. Select a finding to open its record. See Optimize Findings.
One anomaly can cover a multi-day episode, up to 31 days. The daily refresh extends the same record while the increase continues. Detection runs on newly pulled billing data, so turning Daily refresh off also stops new anomalies from being found.
Select Mark reviewed in the detail panel and pick one disposition:
Disposition
Use it when
Unexpected change
The increase needs follow-up or a fix
Expected change
It matches a planned change, such as a launch or migration
Insignificant
The evidence is valid but not worth more work
Success state: the anomaly moves to the Reviewed tab and leaves the Needs review count. A Marked … message, such as Marked Expected change, offers Undo.To change your answer, select Change review. To put it back in the queue, choose Reopen review. The Review reopened message also offers Undo. Reopening keeps the history.
Select Investigate with CloudThinker in the detail panel. The anomaly moves to Investigating right away, and CloudThinker, the built-in assistant, opens a new conversation that already contains the anomaly evidence and the exact cloud connection. It then reads live cost breakdowns and change history in that account. The investigation asks for reads, and any change CloudThinker proposes goes through your Approvals rules.Success state: the conversation ends with a likely cause and the evidence for it, or a plain statement that the available access or data can’t establish one. CloudThinker doesn’t guess a cause.Ask follow-ups in the same conversation:
Which resources inside this service drove the increase, and when were they created or changed?Is the increase still going on today, or did it stop after the flagged days?
Later investigations of the same anomaly can reuse what earlier conversations found. Use Open in Cost Explorer to compare the spike with completed-month spend.
If billing data is restated and no longer supports an anomaly, the agent retracts it with a recorded reason. Retracted records are never deleted. Find them on the Retracted tab, where each one shows the reason and the time it was withdrawn. An anomaly in Investigating or Reviewed can’t be retracted, because a person is already working on it.
There’s no alert per anomaly. Two Optimize digests list new anomalies that nobody has reviewed yet, plus a count of older ones still waiting for review. Turn each one on or off on Notifications.
A workspace the organization owns may have no owner. Under the defaults, the owner gets no weekly email until they turn it on, and Developers and Viewers get neither digest. Everyone else has to check Optimize → Anomalies or the Recent anomalies widget on Overview.
Cause: detection needs 14 finalized days of history per service. Check: the page shows Baseline preparing with how many finalized days are available. Fix: wait for billing history to build up. If the account is older, check that the daily refresh is on in the Optimize page header.
A spike I can see in my cloud console isn't listed
Cause: the provider hasn’t finalized that day’s billing yet, the increase is below the size threshold, or it’s a decrease. Check: compare the date with Billing data through.
Mark reviewed or Investigate with CloudThinker is missing
Cause: your role is Viewer, or the anomaly is retracted. Fix: for a Viewer, ask a workspace Admin for the Developer role. A retracted record is read-only: check the Retracted tab for the reason.
An alert says Optimize refresh is paused or data may be stale
Cause: the last billing refresh failed, for example because of a missing permission or an unreadable billing source. The last good evidence stays readable, and the cloud connection stays connected. Fix: follow the alert. Use Copy policy if it shows a missing permission, Check connection to review credentials, then Retry refresh.
