Anomaly Detection Sensitivity Tuning

Published · Last updated: May 2026 · 3 min read

Who this is for

Anyone who wants CloudAIPilot to catch unexpected cost spikes or drops automatically, and who wants to tune the sensitivity to reduce false alerts.

What you will complete

Understand how cost anomaly detection works, interpret anomaly alerts, and adjust sensitivity to match your spend patterns.

Before you begin

At least 14 days of billing data recommended for reliable anomaly detection.
Navigate to FinOps → Anomalies card.

How anomaly detection works

CloudAIPilot builds a baseline model of your expected daily spend based on recent history. When actual spend for a day deviates significantly from the baseline — either much higher or much lower — an anomaly is flagged.

What triggers an anomaly alert:

A single day's spend is more than 2× the expected baseline (spike)
A single day's spend is less than 50% of the expected baseline (unexplained drop, which may indicate an outage)
A multi-day trend that diverges significantly from the projected path

What does not trigger anomalies:

Gradual cost growth that stays within the expected trend
Predictable events that match historical patterns (e.g., a monthly data transfer batch)

Reading anomaly cards

Each anomaly appears as a card showing:

Date — when the anomaly occurred
Provider and account — which cloud account had the anomalous spend
Actual vs. expected — how much was actually spent vs. what was expected
Delta — the percentage difference (e.g., "+185% above expected")
Likely cause — if the system can correlate with a known event (new server provisioned, backup ran, deploy happened), it notes the likely cause

Sensitivity levels

The anomaly detection sensitivity can be adjusted in the Anomalies card settings:

High sensitivity: Flags smaller deviations (15–20% above baseline). More alerts, but catches subtler problems.
Medium sensitivity (default): Flags significant deviations (50%+ above baseline). Balances signal vs. noise.
Low sensitivity: Only flags very large deviations (100%+ above baseline). Fewer alerts, only catches major spikes.

When to increase sensitivity:

You have a stable, predictable spend pattern and want to catch small unexpected changes.
You are running a tightly budgeted operation where even 20% overruns matter.

When to decrease sensitivity:

You are experiencing many false positives (anomalies flagged for normal operational events like scheduled batch jobs or monthly data transfers).
Your spend is inherently variable and the model cannot establish a stable baseline.

Dismissing false-positive anomalies

If an anomaly is expected (e.g., you provisioned 5 new servers intentionally and the cost spike reflects that):

Click the anomaly card.
Click Dismiss or Mark as expected.
The anomaly is removed from the active list. Future similar events may still be flagged if the model does not incorporate the change into the new baseline.

What success looks like

Anomalies appear for unexpected cost spikes (a forgotten test server, an accidental resource creation, a data egress surge).
Normal operational events (deployments, scheduled backups, monthly batch jobs) do not trigger anomalies after the sensitivity is properly tuned.

Common errors and fixes

"I get anomaly alerts every week for the same pattern" Cause: A weekly recurring cost (weekly data transfer, weekly backup to cold storage) is being detected as an anomaly because it appears as a spike vs. daily average. Fix: Lower the sensitivity, or if the weekly event is consistent, the model will eventually incorporate it into the baseline after 4–6 weeks of data.

"No anomalies are ever detected even though my costs clearly spiked" Cause: Sensitivity may be too low, or there is insufficient baseline history for the model. Fix: Increase the sensitivity setting. Ensure 14+ days of billing history are available.