Alerts & Anomaly Detection

Overview

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

• Anomaly Detection: Uses machine learning to model expected spend and flags deviations that exceed your configured thresholds.
• Threshold Alerting: Triggers when the daily value of the selected measure meets or exceeds the threshold you define.

Report-linked alerts inherit the report's data source, dimensions and filters, and evaluate the measure selected for the alert. Alert evaluation uses its own time windows; changing the report's displayed date range does not change those windows. 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 Amount and Minimum Percent 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

Creating an Alert

1. Open or build a report in the Reporting Engine with the data source, groupings and filters you want the alert to watch.
2. Save the report. An alert must be attached to a saved report; the create action stays disabled until the report is saved.
3. Open the report's alerts (the bell icon / Manage Alerts) and choose Create New Alert.
4. Configure the alert in the Create Alert form and click Create Alert.

The Create Alert form is a single view (no tabs) with three parts: the trigger condition, a read-only scope, and notifications.

Alert details

• Alert Name - a descriptive label for the alert. Required.
• Alert Type - choose one:
  • Anomaly alert - alerts when the daily value deviates from its expected range, based on historical patterns.
  • Threshold alert - alerts when the daily value crosses a fixed amount you set.

Trigger condition

Defines when the alert fires. The condition is evaluated separately for each grouping in the scope.

Measure - Report-linked alerts evaluate only one measure that is part of your report. You can create as many alerts as you want, referencing different measures for each alert.

Direction (anomaly alerts, only) - alert on increases, decreases, or both. Decreases include a 3-day grace period.

You set both of the settings below, and a day has to clear both before it alerts - together they keep alerts on meaningful spikes instead of everyday noise.

Minimum Amount (anomaly alerts only) — The minimum difference from the expected value, expressed in the selected measure's unit. This can be a currency amount, percentage or another quantity.

Minimum Percent (anomaly alerts, only) - the same difference, measured as a percentage of the expected value. Anything smaller is ignored.

Threshold value (threshold alerts, only) - the daily amount of the selected measure that triggers the alert. Must be greater than 0.

Report-linked alerts use the report's filters. The alert form has no separate tax-exclusion setting.

Scope (read-only — inherited from the report)

Defines the data this alert watches. These values come directly from the report and cannot be edited in the alert form. If you want to change them, change the report.

Updating report scope updates linked alerts. The alert resolves the report's data source, dimensions and filters at evaluation time while retaining its selected measure. Changes to the report's date range do not change the alert evaluation dates.

Notifications

At least one subscriber or Slack channel is required.

• Subscribers - Ternary users and/or external email addresses. Internal users are chosen from the list; a typed value is added as an external email if it is a valid address.
• Slack - enable and select target channels (requires a Slack integration).

Report access disclosure. Because an alert notifies its recipients, saving may broaden the report's visibility so those recipients can open it:

• "[Name] will be given access to this report." / "[Name] and N more will be given access to this report."
• "This report will be made visible to your whole organization." (when all users are selected)
• "External email recipients won't have report access."

Broadening is additive only, it never reduces a report's visibility.

Editing and deleting alerts

• Edit - opens the same form pre-filled; Save to apply.
• Delete - a confirmation modal shows the subscriber impact (how many emails and Slack channels will no longer be notified) before you confirm. Deletion cannot be undone.

---

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 and Alert Rules

View an alert rule as a report

Each alert rule has a View as Report action (in its action menu) that opens the data the alert evaluates in the Reporting Engine. For report-linked alerts this opens the rule's saved report - the same measure, groupings, and filters the alert watches - so you can explore the numbers behind it. Older alerts that aren't linked to a report open a new, pre-scoped report built from the rule's own measure, groupings, and filters instead.

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 the selected measure 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, the observed value 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 the value normalized after the anomaly or continued trending.

Table
The table breaks down the alert's recorded measure for the event day using the configured groupings (or resource ID, category, and charge description if no groupings are set). Values use the measure's unit.

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.