Detectors & Signals
This guide explains how anomaly detectors in Cloudaware FinOps use baselines, signals, and sensitivity, and how to tune them to balance early warning with noise reduction.
Key Concepts
Metric or signal – the time series being monitored (for example, daily cost for a service, account, application, or tag; or a usage metric such as storage GB or requests).
Baseline – the “normal” pattern for a signal over time, learned from historical data.
Anomaly – a data point or window that deviates from the baseline by more than a defined threshold.
Sensitivity – how aggressively a detector flags deviations; higher sensitivity finds more anomalies but may increase noise.
Scope – the slice of spend/usage being monitored (for example, by account, BU, application, environment, or customer).
Types of Signals to Monitor
Common anomaly signals include:
Total daily cost by scope – account, subscription, project, BU, application, or environment.
Service‑level spend – cost by service (for example, compute, storage, data transfer, managed databases).
Waste‑related metrics – spend on idle or underutilized resources highlighted by waste detection and rightsizing policies.
Start with a small set of high‑value signals (such as total daily cost per app or BU) before expanding to more granular metrics.
Baselines and Seasonality
Cloud cost often exhibits patterns:
Weekday vs. weekend usage.
Start‑of‑month or end‑of‑month processing.
Seasonal peaks and troughs.
Anomaly detectors aim to capture these patterns in the baseline so that predictable cycles do not constantly trigger alerts. When evaluating anomalies, compare them to expected seasonal behavior, not just to the previous day.
Sensitivity and Thresholds
To manage noise:
Start with moderate sensitivity for new detectors and adjust based on experience.
Use relative thresholds (for example, “more than 30% above typical daily spend”) and, where appropriate, absolute thresholds (for example, “increase greater than $X”).
Treat high‑sensitivity detectors as candidates for dashboards or periodic review, and reserve notifications for the most critical signals.
Exclusions and Known Changes
Not all unusual behavior is a problem. Reduce false positives by:
Temporarily suppressing alerts for known events (for example, planned migrations, major load tests, or product launches).
Excluding low‑value scopes or services from detection (for example, tiny dev accounts where anomalies do not matter).
Reviewing recurring “expected anomalies” and either adjusting baselines or updating documentation to reflect new normal behavior.
Relation to Other Features and Modules
Use anomaly signals to feed Optimization work (rightsizing, commitments, scheduling, waste cleanup).
Combine anomaly detection with Compliance Engine policies that identify specific waste patterns (for example, unattached volumes, idle instances) and surface savings estimates.
Include anomaly trends on Reporting & Analytics so leadership can see when unexpected cost behavior is being investigated and resolved.