Anomaly Detection¶
Anomaly Detection helps FinOps, finance, and engineering teams find unusual cloud spend, understand what changed, and review forecasted risk before it becomes a bill surprise.
CloudVerse AI separates anomaly review into observed spend changes and forecasted future risk. Use detected anomalies to investigate what already happened, and predicted anomalies to review what may happen next.
When to use it¶
- A service, account, or organization total changed unexpectedly.
- You need to explain why the current bill is higher or lower than expected.
- You want to identify the account, service, or Perspective driving a spend change.
- You need to review forecasted spend risk before the risk date.
- You want a daily queue of spend changes that need finance or engineering review.
Open Anomaly Detection¶
Go to Cost Management > Anomalies & Forecasts from product navigation.
Some tenants may still see the module as Anomaly Management during rollout.
What the Dashboard shows¶
The Dashboard includes a Spend increase anomalies card for a quick 30-day health check.
| Field | Meaning |
|---|---|
| Spend increase cases (30d) | Number of open spend increase anomaly cases found in the last 30 days. |
| Critical | High-severity cases that should be reviewed first. |
| Extra usage spend | Estimated spend above expected usage for the open cases. |
| vs last month | Change in anomaly case count compared with the previous 30-day period. |
| Top items | The largest anomaly contributors, usually an organization-wide, account, service, or provider portfolio case. |
Click the arrow on the card to open Anomalies & Forecasts filtered to detected spend increases.
Dashboard numbers are a summary
The Dashboard card is a starting point. Use the anomaly table and drawer for the exact scope, affected dates, expected spend, actual spend, and investigation details.
Tabs¶
| Tab | What it shows | Use it for |
|---|---|---|
| Overview | Summary of anomaly activity, impact, affected accounts, and review queues. | A quick read of what needs attention. |
| Detected anomaly | Observed spend increases and spend drops that already happened. | Explaining bill movement and finding root cause. |
| Perspective anomalies | Detected anomalies inside business scopes such as teams, products, or environments. | Routing anomalies to the right owner. |
| Predicted anomaly | Forecasted risks where future spend may exceed the expected range. | Reviewing likely future overspend before the risk date. |
Spend increases and spend drops¶
Detected anomalies can be viewed by direction.
| Direction | Meaning | Typical action |
|---|---|---|
| Spend increase | Actual usage spend was above the expected range. | Investigate owner, deployment, usage, pricing, or configuration change. |
| Spend drop | Actual usage spend was below the expected range. | Confirm whether the drop is expected, missing data, service outage, migration, or shutdown. |
Spend drops are not always bad. Treat them as review signals. A drop can represent savings, but it can also indicate missing billing data, disabled workloads, failed ingestion, or a production issue.
Scope levels¶
An anomaly is always tied to a scope. The scope tells you what the chart and impact numbers represent.
| Scope | Meaning | Example |
|---|---|---|
| Organization-wide | The anomaly is visible at total organization spend level. | Total usage spend is above expected. |
| Provider portfolio | The anomaly is across one provider portfolio. | Azure portfolio spend increased. |
| Account | The anomaly is for one cloud account, subscription, or project. | One Azure subscription increased. |
| Service | The anomaly is for one service inside one account. | Log Analytics spend inside one subscription increased. |
| Perspective | The anomaly is inside a business mapping such as team, product, or environment. | The Payments Perspective increased. |
Account vs service anomalies
A service anomaly inside an account is not the same as total account spend. If the table or drawer says Service anomaly, compare it with Cost Explorer filtered to the same account and service. Comparing it with total account spend can make the anomaly look incorrect.
Detected anomaly table¶
The detected anomaly table is the main review queue for observed spend changes.
| Column | Meaning |
|---|---|
| Date | The latest date in the anomaly case. |
| Provider | Cloud provider or source where the anomaly was found. |
| Incident | The affected scope, such as service, account, or organization-wide spend. |
| Trend 30d | Mini trend showing recent spend and anomaly points. |
| Pattern | How the spend changed, such as spike, recurring, reactivated spend, or cost drop. |
| Impact | Estimated difference between actual usage spend and expected usage spend. |
| Expected usage | The spend CloudVerse expected for the selected scope and date. |
| Usage actual | The actual usage spend observed for the selected scope and date. |
| Impact % | Percent difference between actual and expected spend. |
| Status | Review state, such as open, acknowledged, dismissed, or closed. |
Use filters to narrow by date range, direction, incident type, pattern, provider, severity, and status.
Detected anomaly drawer¶
Select a detected anomaly row to open the drawer.
| Section | What to review |
|---|---|
| Summary cards | Scope, account, service, date, impact, actual spend, expected spend, severity, and status. |
| Trend chart | Actual spend compared with expected usage for the affected scope. Red points mark anomaly days. |
| Affected accounts or services | Accounts, services, or resources contributing to the anomaly. |
| Next action | Suggested investigation path, such as inspect service resources or verify a cost drop. |
| Technical details | Model and signal details for advanced review. |
Drawer actions¶
| Action | Use it when |
|---|---|
| Acknowledge | The anomaly is valid and someone is reviewing it. |
| Dismiss | The anomaly is not useful, expected, duplicate, or not actionable. |
| Closed | The case is no longer active because the signal ended or the issue was resolved. |
Acknowledging or dismissing an anomaly changes its review state. It does not change the underlying spend data.
Perspective anomalies¶
Perspective anomalies use the same detected anomaly logic, but the scope is a business view instead of only provider, account, or service.
Use Perspective anomalies when each team, product, cost center, or environment needs its own anomaly review queue.
Before relying on Perspective anomaly results, confirm the Perspective rules correctly map spend to the expected owners. If a Perspective has incomplete rules, anomalies may appear under the wrong business scope or not appear at all.
Predicted anomaly table¶
Predicted anomalies are forecasted risks. They are not confirmed anomalies.
| Column | Meaning |
|---|---|
| Review by | Date by which the risk should be reviewed. |
| Provider | Provider where the risk is forecasted. |
| Account | Account, subscription, project, or service scope affected by the forecast. |
| Trend | Mini forecast trend showing recent actual spend and forecasted spend. |
| Risk period | Future date or date range where spend may exceed the expected limit. |
| Possible extra spend | Forecasted spend above the expected upper limit for the risk period. |
| Signal | Strength of the warning based on forecast confidence and risk evidence. |
Use the View filter to choose active future risks or other available forecast states.
Predicted anomaly drawer¶
The predicted anomaly drawer explains why CloudVerse thinks future spend may exceed the expected range.
| Section | What it means |
|---|---|
| Risk summary | The affected scope, risk period, review date, possible extra spend, and signal. |
| Spend forecast | Historical spend, forecasted spend, expected upper limit, and risk days. |
| Likely drivers | Account or service areas most likely contributing to the forecasted risk. |
| Why we trust this | Simple confidence explanation based on recent pattern quality and available history. |
| Technical details | Forecast generation date, training cutoff, selected model, and data freshness. |
Forecast chart terms¶
| Chart item | Meaning |
|---|---|
| Actual spend | Historical usage spend for the exact anomaly scope. |
| Forecast spend | Expected future usage spend predicted by the model. |
| Expected upper limit | The upper range CloudVerse considers normal for that scope. |
| Risk days | Future dates where forecast spend is above the expected upper limit. |
Predicted anomalies are warnings
A predicted anomaly means future spend may exceed the expected range. It is not a confirmed overspend until actual billing data arrives.
Signal, severity, and confidence¶
These labels help prioritize review.
| Term | Meaning |
|---|---|
| Severity | Business impact of the detected anomaly, based mainly on spend difference and score. |
| Signal | Strength of a predicted anomaly warning. Strong signals should be reviewed first. |
| Confidence | How much evidence supports the anomaly or forecast. Higher confidence means the pattern is clearer and the data is more reliable. |
For end users, focus on the label and next action. Technical model terms are available for analysts who need to inspect how the signal was produced.
Investigation workflow¶
1. Start with the right direction¶
Use Spend increase when the bill is unexpectedly higher. Use Spend drop when spend is unexpectedly lower or data may be missing.
2. Confirm the scope¶
Check whether the anomaly is organization-wide, account-level, service-level, or Perspective-level. Match the same scope when validating in Cost Explorer.
3. Read the chart¶
Compare actual spend with expected spend. Red points identify anomaly or risk days. For predicted anomalies, separate historical spend from forecasted spend.
4. Review likely drivers¶
Look for the account, service, or Perspective that contributes most to the impact. If the drawer shows a service anomaly, investigate that service first.
5. Validate in Cost Explorer¶
Open Cost Explorer and apply the same date range, provider, account, service, cost type, and currency. Do not compare service-level anomaly values with total account spend.
6. Decide the next action¶
Acknowledge the case if it needs review, dismiss it if it is expected or not useful, and record the reason when escalating to the owner.
Common questions¶
Why does the anomaly value not match my Dashboard total?¶
The anomaly may be for a service, account, or Perspective, while the Dashboard total may show the whole organization or account. Match the exact anomaly scope in Cost Explorer before comparing numbers.
Why do I see a spend drop anomaly?¶
A spend drop means usage spend was lower than expected. It may be expected savings, but it can also indicate missing billing data, stopped workloads, outages, or ingestion delay.
Why did an anomaly close?¶
An anomaly closes when the abnormal pattern stops appearing in the scoring window or when it is no longer active after reruns.
Why is a predicted anomaly not visible after the risk date?¶
Predicted anomalies are future-risk warnings. After actual spend arrives, use detected anomalies and Cost Explorer to confirm what happened.
Why do predicted anomaly amounts change?¶
Forecasts update as new billing data arrives. A newer forecast may increase, decrease, or remove a risk depending on the latest spend pattern.
Best practices¶
- Review high-severity detected anomalies before lower-impact cases.
- Treat strong predicted anomalies as early warnings, not final proof.
- Always match provider, account, service, date range, cost type, and currency when validating in Cost Explorer.
- Use Perspective anomalies only after Perspective rules are verified.
- Dismiss expected cases so active queues stay useful.
- Review spend drops when data freshness or workload health matters.
Related pages¶
- Dashboard — review anomaly summaries from the main dashboard.
- Cost Explorer — validate anomaly scope and spend details.
- Perspectives — create business scopes for Perspective anomalies.
- Notification Settings — configure anomaly alert delivery.
- Missing recommendations and anomalies — troubleshoot empty anomaly results.