Anomaly Detection
StackSpend automatically detects unusual spend patterns after every provider sync — no configuration required. This guide explains how detection works, what alert types exist, and how to act on anomalies.
How it works
After each provider sync, StackSpend analyses your cost data and compares it against historical baselines. If spend deviates beyond expected bounds, an anomaly is created and surfaced in your Inbox and Tasks.
There is nothing to configure. Detection runs automatically for every connected provider as soon as new cost data arrives.
How baselines are built
StackSpend computes statistical baselines per provider and per service from your historical cost data. For each dimension, it tracks:
| Statistic | Purpose |
|---|---|
| Mean | Centre of the expected spend range |
| Standard deviation | Width of the normal spend band — how much variation is typical |
| Median | Robust centre that is less sensitive to past spikes |
| High-spend marker | Upper bound that filters routine high-spend periods from true anomalies |
The sample size behind each baseline is tracked internally. Confidence in detection increases as more data accumulates — detection with less than two weeks of history may produce more false positives or miss subtler deviations.
Alert types
StackSpend raises four distinct anomaly types. Each type indicates a different pattern and calls for a different response.
| Type | What it means | Common causes |
|---|---|---|
| Spike | Actual spend significantly above the expected baseline for that period | Runaway jobs, misconfigured autoscaling, traffic surge, accidental resource creation |
| Drop | Spend significantly below baseline — useful for detecting service outages or unexpected shutdowns | Broken deployment pipeline, accidentally terminated resources, provider outage, credential revocation |
| Trend change | Spend trajectory shifting upward or downward across multiple periods, even if no single period looks anomalous | Growing usage that will exceed budget, pricing change, gradual resource leak |
| New service | A service or model that has not appeared before starts incurring cost | Shadow IT, new team using a provider feature, accidental service activation |
Severity levels
Each anomaly is assigned a severity based on two factors: how far spend has deviated from the normal range, and the absolute dollar impact. Both matter — a large deviation on a low-cost service may be less urgent than a moderate deviation on a high-cost one.
| Severity | Typical signal | Inbox label |
|---|---|---|
| Low | Minor deviation, small absolute delta | For you |
| Medium | Meaningful deviation or growing trend | For you |
| High | Large deviation or significant dollar impact | Needs attention |
| Critical | Extreme deviation with high absolute cost impact | Needs attention |
Alert lifecycle
Anomaly alerts move through a simple lifecycle so your team can track what has been looked at and what is resolved.
| State | Meaning |
|---|---|
| New | Just detected, no one has looked at it yet |
| Acknowledged | A team member has seen it and is investigating |
| Resolved | The anomaly has been investigated and closed, optionally with a note explaining the cause |
| False positive / Dismissed | The alert was not a real issue — dismissing it feeds back to the detector to improve future accuracy |
Acting on anomalies
There are three places to work through anomaly alerts:
Inbox
The Inbox is the primary triage surface. Alerts are split into two tabs:
- For you — lower-severity items assigned or relevant to you
- Needs attention — High and Critical alerts requiring prompt action
Tasks
The Tasks page shows all open anomaly-derived tasks. Filter by the Alert type column to focus on spikes, drops, trend changes, or new services.
Data Explorer
Clicking into any anomaly opens the Data Explorer pre-filtered to the relevant provider and service, so you can immediately drill into the underlying cost data.
Teaching the detector
StackSpend's anomaly detector improves over time based on your feedback:
- Dismissing as “false positive” — signals to the detector that this pattern is expected. Future occurrences of the same pattern are less likely to fire at the same severity.
- Resolving with a note — records context alongside the anomaly (e.g. “end-of-quarter data migration”). Notes are visible to your whole team, building institutional memory around recurring spend events.