Anomaly Detection

Overview

Detect unexpected changes or irregularities in cloud spend using alert rules. Ternary supports two modes of alerting:

• Anomaly Detection (AI Detection): Uses machine learning to model expected spend and flags deviations that exceed your configured thresholds.
• Threshold Alerting: Triggers when daily spend meets or exceeds a static dollar amount you define.

This article will guide you through setting up alert rules of both types, and managing and investigating alerts once triggered.

---

How the Detection Engine Works

Understanding the engine behind AI Detection helps you configure rules that fire when you need them to — and stay quiet when you don't.

The model and its training window

Ternary uses a time series machine learning model, which learns seasonality patterns (daily, weekly, etc.) for each unique combination of dimensions in your rule's Group By configuration. Each combination gets its own independently trained model with its own expected range.

The model trains on a rolling 90-day window of historical billing data, ending 7 days before today. That 7-day gap is intentional — it's the active detection window, the period the model evaluates for anomalies. Data inside the training window always returns NULL bounds and will never generate an alert.

Example: If today is May 21, the model trains on Feb 13 – May 14, and evaluates May 14 – May 21 for anomalies.

The model constantly retrains, so expected ranges stay current as your spending patterns evolve.

How expected ranges are calculated

For each day in the detection window, the model produces an upper bound and a lower bound — the predicted cost range at 90% confidence. A data point is flagged as an anomaly when actual spend falls outside this range.

Because the model naturally expects roughly 1 in 10 data points to fall outside the bounds even in stable workloads, your rule's Minimum Deviation Amount and Minimum Deviation % settings act as a second filter layer to suppress low-severity detections.

Why sparse data won't generate false positives

The engine automatically filters out time series that lack enough historical data points to model reliably. If a particular dimension combination has too few billing records, it is excluded from evaluation entirely — so intermittent or new workloads won't generate erratic alerts.

---

Alert Rules

Create an alert rule

Ternary allows you to create custom alert rules. The create form is organized into two tabs: Configuration and Notifications.

Configuration tab

Name
Use a descriptive name so others understand the rule's scope at a glance — for example, "Non-Production – $50 – By Service" or "Prod Compute – $500 Threshold."

AI Detection Enabled
This toggle switches between the two alert modes:

• On (Anomaly Detection): Uses machine learning to model expected spend and detect deviations. Exposes the Minimum Deviation Amount, Minimum Deviation %, and Direction fields.
• Off (Threshold): A simple static threshold. Alerts when daily spend meets or exceeds the configured Spend Threshold amount.

Minimum Deviation Amount (AI Detection only)
The absolute dollar amount by which spend must exceed the expected bounds before an alert fires. Anomalies below this dollar amount are ignored regardless of how unusual they are statistically.

Tip: Start with a higher value than you think you need and lower it over time. Use a 45–60 day lookback when testing — if your threshold generates hundreds of historical alerts, it's too low.

Minimum Deviation % (AI Detection only)
The percentage by which spend must deviate from the violated bound before an alert fires. This works in combination with Minimum Deviation Amount — both conditions must be met for an alert to trigger. For example, $100 and 10% means spend must be both $100+ and 10%+ outside the expected range. This two-condition approach helps filter out cases where a large absolute deviation is actually a small relative one (or vice versa).

Spend Threshold (Threshold mode only)
The dollar amount at which an alert fires. An alert is generated for any day where spend meets or exceeds this value.

Direction (AI Detection only)
Which direction of spend change to alert on:

• Increases and Decreases (default)
• Increases Only — useful for cost control where drops are acceptable
• Decreases Only — useful for detecting underutilization or dropped workloads

Note that decrease anomalies always carry a built-in 3-day grace period before alerting, to account for late-arriving billing data.

Exclude Tax
Toggle to exclude tax charges from alert evaluation. Useful when tax fluctuations would otherwise cause false positive alerts.

Filters
Scope the dataset the rule evaluates. Available filter dimensions:

• Billing Accounts
• Sub Account IDs
• Sub Account Names
• Services
• Charge Descriptions

For example, create separate rules for Production and Non-Production spend with different thresholds for each.

Group By
Controls how spend is split into independent time series for evaluation. In AI Detection mode, each unique combination of the selected dimensions gets its own ML model with its own expected range.

• No groupings: All spend matching your filters is summed into a single time series. A $200 spike in one service could go unnoticed if your total daily spend is $50,000.
• With groupings: Spend is broken out so anomalies can be detected within each slice. For example, grouping by Service means Compute, Storage, and BigQuery each get their own expected range. Adding Sub Account ID means each (Service, Sub Account) pair — such as "Compute in project-prod" and "Compute in project-dev" — is tracked independently.

Tradeoff: Finer groupings give more granular detection but produce more alerts, and dimension combinations with too few data points are automatically excluded from modeling. Start broad (e.g., Service only) and add dimensions if you need finer resolution.

Notifications tab

Email Notifications
Toggle email notifications on or off. When enabled, select which Ternary users receive alert emails and optionally add non-account addresses (e.g., distribution lists or executives without Ternary accounts).

Slack Notifications
Toggle Slack notifications on or off. When enabled, select which Slack channels receive alert messages. Requires a Slack integration to be configured in your tenant.

---

Recent Anomalies Triggered

This section shows your most recent alert events, filtered by the selected date range (default: last 30 days). Each row includes the source alert rule name, the event date, groupings, actual value, delta, a sparkline chart, and any linked cases.

Status: Each alert event has a changeable status to track investigation progress: Active, Investigating, Unresolved, and Resolved.

---

Anomaly Groups

A list of each alert rule with the number of anomalies triggered in the selected date range and the most recent anomaly date. Each section is expandable to view additional details, and a View button opens the specific alert event.

Manage Anomaly Alert Rules

Delete an alert rule
Permanently removes the rule and all of its historical anomaly events. This action cannot be undone.

Archive an alert rule
Pauses scanning for new anomalies while preserving all previously captured events. You can unarchive at any time to resume detection.

Delete an anomaly event
Permanently removes a single anomaly event. The parent rule and all other events remain unaffected.

---

View Alert Event

Clicking View opens the detail panel for a specific alert event.

Key measures:

Chart
Displays approximately 90 days of spend centered around the alert event (75 days before, 15 days after), filtered for this rule's configuration. The upper and lower prediction bounds appear in grey, actual spend as a blue line, and the alert event as a red dot. This wider view — extending 15 days past the event — lets you assess whether spend normalized after the anomaly or continued trending.

Table
The top 5 cost drivers for the day of the alert, based on configured groupings (or resource ID, category, and charge description if no groupings are set). Useful for quickly identifying the primary spend driver, including usage amount and cost for the event day.

Identify Root Cause
The Identify Root Cause button opens a detailed report in the Ternary Reporting Engine, pre-filtered to the anomaly's timestamp, filters, and groupings. From there you can add additional groupings and filters to isolate the root cause.

Cases
Create a new case or link an existing one directly from the alert detail view. Cases optionally integrate with Jira via Ternary's bidirectional Jira integration. See Case Management for details.