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 daily spend meets or exceeds a static dollar amount you define.

Alert rules are created directly from a report, so an alert always evaluates the exact data the report shows. 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. Alert rules are created from a report, so their scope is never ambiguous — the alert evaluates exactly what the report shows.
2. Open or build a report in the Reporting Engine.
3. Save the report. An alert must be attached to a saved report; the create action stays disabled until the report is saved.
4. Open the report's alerts (the bell icon / Manage Alerts) and choose Create New Alert.
5. 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 smallest dollar difference from expected spend that counts. Anything smaller is ignored.

Minimum Percent (anomaly alerts, only) - the same difference, measured as a percentage of expected spend. 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.

Exclude tax from alert evaluation - leaves tax out of the evaluation.

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 the report updates the alert. Scope is resolved from the report at evaluation time, not copied when the alert is created. If you change the report's filters, groupings, or date scope, every alert linked to that report begins evaluating the new scope on its next run — no need to re-open or re-save the alerts.

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 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.