Tuning Anomaly Detection

In this article we will demystify the anomaly detection algorithm and explain how this works under the hood to help you with tuning the threshold multiplier setting as shown below.

🔍 Standard Deviation in calculating the anomaly?

Standard deviation is a measure of how much values normally vary from the average.  We use this to look for anomalies.

• If daily cost changes are usually small and steady, the standard deviation will be low

• If daily cost changes jump around a lot, the standard deviation will be high

So in cost anomaly detection, the standard deviation tells us:

“What is a normal amount of fluctuation?”

That way, we don’t flag every tiny cost change as a problem — only the ones that are well outside the usual pattern.

📌 How It Fits Into the Algorithm

1. Take the last 30 days of cost changes

2. Compute the standard deviation → this gives the “normal movement range”

3. Multiply it by a threshold multiplier (1.0, 1.5, 2.0, etc.)

4. If today’s cost change is outside that range → flag as anomaly

⚙️Threshold Multiplier

In Turbo360 we use a setting called threshold multiplier which allows you to configure the sensitivity of the anomaly detection within the cost management group.

The below table will illustrate how the threshold multiplier will impact the alert being fired or not in a potential anomaly scenario.

✅ Notes for above table:

• The standard deviation stays fixed at 50 in this example — only the multiplier changes

• The anomaly threshold increases as the multiplier increases

• The cost change (120) stays constant — this shows how same event behaves differently based on tuning

• This makes it easy to explain why noise vs. signal depends on configuration

Normal Process

When setting up a new cost management group with monitoring we normally recommend that unless you have specific plans, start with the anomaly detection set to 1 and you will get a feel for the kinds of anomalies you might get on a day to day basis for a period of time.

Once you have a feel for the application the threshold multiplier can be tuned to an appropriate setting based on your comfort level for this application.

📊 Understanding: 7-Day Rolling Standard Deviation of Cost Changes

The below table will give you an illustration of how a rolling standard deviation is calculated based on a 7 day rather than 30 day cycle to simplify things.

When would an anomaly signal

Consider the below parameters:

🔹 We have the above table of costs

🔹 Our threshold multiplier is set to 2.0

The below table shows when we would expect the anomaly to trigger and an alert to be sent.

🔥 Result

✅ Only Day 8 triggers an anomaly
Because the spike (+60) was outside the tolerated range for that point in time.

Even though the standard deviation stays high for several days afterward, the cost changes return to small values, so no repeated anomalies are fired — this is exactly the benefit of a rolling standard deviation model.

🧠 Why Only One Alert?

Because the system is designed to catch the sudden spike, not punish the user for the next 7 days while the rolling model cools down.

This is the difference between:

🔍 How the Cost Anomaly Detection Algorithm Works [Deep Dive]

We review the service level costs within the cost scope on the tree view where the monitoring is configured.

1. Collect Cost History

   • Retrieve the last 30 days of daily cloud cost data.

   • For each day, calculate the day-over-day cost change:
     CostChange[day] = Cost[day] – Cost[day-1]

2. Establish Normal Behaviour

   • Compute the standard deviation of those 30 daily cost changes.

   • This gives a baseline of what “normal fluctuation” looks like.

3. Check Today’s Cost Movement

   • Compute today’s change:
     TodayChange = Cost[today] – Cost[yesterday]
     (example: 29-10-2025)

4. Apply the Anomaly Threshold

   • An anomaly is detected if:
     abs(TodayChange) > (StandardDeviation × ThresholdMultiplier)

5. Threshold Multiplier Controls Sensitivity

   • Smaller multiplier (e.g., 1.0 – 1.5) → more sensitive → more alerts (good for early warning)

   • Larger multiplier (e.g., 2.0 – 3.0) → less sensitive → only large spikes/drops alert

When we identify an area where they looks to be an anomaly we then look for potential resources which cause this cost spike.

📊 Example Scenario

We’ll use 7 days instead of 30 for simplicity — the logic is identical.

1️⃣ Calculate Daily Cost Change

CostChange[day] = Cost[day] – Cost[day-1]

So our last 6 changes are:

[ +2, -1, +4, -1, +56, -2 ]

2️⃣ Compute Standard Deviation of These Changes

Step A — Mean (average) cost change

Add all 6 changes:

2 + (-1) + 4 + (-1) + 56 + (-2) = 58

Divide by 6:

58 ÷ 6 = 9.6667   (mean)

Step B — Variance (average squared deviation from mean)

Sum of squared deviations:

58.78 + 113.78 + 32.11 + 113.78 + 2146.78 + 136.11 = 2601.34

Divide by number of samples (6):

2601.34 ÷ 6 = 433.56   (variance)

Standard deviation = √variance:

√433.56 ≈ 20.82

So:

StandardDeviation ≈ 20.82

3️⃣ Check Today’s Change Against Threshold

Today’s change was:

-2

Assume the ThresholdMultiplier = 2.0

So anomaly threshold is:

20.82 × 2.0 = 41.64

Now we check:

abs(-2) = 2  →  2 < 41.64  ✅ No anomaly

4️⃣ But What About Yesterday’s Big Spike?

Yesterday (27-Oct) change was +56

abs(56) = 56  →  56 > 41.64  ❗ Anomaly detected

So the system would have flagged the jump from $104 → $160, but not today’s small drop back to $158.