Radar

Radar reports the unusual cost behavior that DigiUsher finds in your bills. This behavior is a spike, a change of pattern, or a resource that appeared or disappeared. Open Radar from Spend > Radar in the left sidebar.

Use Radar when you need to:

• Find the cause of an unexpected bill.
• Read the cost changes of the month in the order of their impact.
• See the evidence behind a marked day, and not only the mark.
• Separate a real cost increase from a cost that moves from one pool to another.
• Get an alert for the anomalies inside a saved SpendIQ perspective.

The badge beside Radar in the sidebar counts the anomalies of the current month up to today, without a filter. The page itself uses the date range that you select. The number in the badge and the number above the timeline are therefore often different.

Filters

Severity and Type are multi-select. Select the values, then click Apply.

Clear all appears after you set a filter chip, and it removes the chips only. The date range and the sort order are the anchors of the view, so they do not change.

Summary

Four cards summarize the anomalies that match your filters and your date range:

• Total anomalies gives the number of anomalies in the selected range.
• By severity gives the number at High, at Medium, and at Low.
• Largest impact gives the one anomaly with the highest cost impact. It also gives the object of the detection, the date, and the type.
• Most common type gives the type with the most anomalies, and its part of the total.

If you look for the cause of a bill, start at Largest impact. If you look for a systemic problem, and not a single event, start at Most common type.

Timeline

Each anomaly is a card in the timeline. A card gives:

• The object of the detection, as the title.
• The severity, as a colored pill and a colored left border.
• The type.
• The cost impact. Red is an increase, and green is a decrease.
• The date of the detection.
• The scope of the detection.
• Also detected on:, which lists the other objects marked on the same date. If there are none, the card reads No related anomalies on this date.

When you sort by Date (Newest) or Date (Oldest), the cards are grouped under date headings. Every other sort gives a flat list.

Under the timeline, the pagination gives the range that you read, for example Showing 1-50 of 127. It also has Previous and Next.

Scopes

The detection runs at several scopes. One change in your costs can therefore appear more than one time: as an anomaly at the level of a service, and as the anomaly at the level of the organization that it creates. The scope on a card is one of these:

To find a cause, start at the narrow scopes. To see whether the whole bill moved, start at Organization.

Anomaly detail

Select a card to open its details in the same place.

Impact

Detection

Cost Trend plots the daily cost from 14 days before the anomaly to 7 days after it. You can then see whether the marked day is a single event or the start of a new level.

Same-date Anomalies (possible cascade) lists the other anomalies of the same date, with the largest impact first. It also names the scope that probably holds the root cause, for example Check the Service-level anomaly for the likely root cause.

How detection works

Two independent detectors run over your daily costs.

Statistical detection

Three methods examine each cost time series:

DigiUsher marks a day only when at least two of the three methods agree. Three more filters keep the number of anomalies low:

• The cost impact must be $10 or more.
• The deviation must be 5% or more.
• The series must have at least 7 days of history.

Because of this agreement rule, Radar reports many fewer anomalies than an alert with one threshold. For the same reason, the Methods field is useful: a day that all three methods mark is a stronger signal than a day that two methods mark.

Structural detection

Structural detection compares the entities that exist in two periods. It does not compare their cost. The baseline is the period of 30 days that ends 7 days ago. The current period is the last 7 days.

• A new entity exists now, but it does not exist in the baseline. An example is a service that started.
• A disappeared entity exists in the baseline, but it does not exist now. An example is a region that you closed.

Each detection run reports at most 20 new entities and 20 disappeared entities. A large migration therefore cannot fill the page.

Severity

Alerting on a perspective

Radar reports what it finds. An anomaly configuration of a perspective decides which anomaly gets an email. Each configuration adds anomaly rules to a saved SpendIQ perspective. The alert goes out only when the anomaly passes both the cost impact threshold and the severity threshold.

Open System > Guardrails, then the Anomalies card, to reach Perspective Anomaly Configs. Click New config to add one.

The list gives each configuration with its Perspective, Source, Min severity, Min cost impact, and creation date. You can edit a configuration or delete it. The perspective of a configuration is fixed at the creation. To monitor a different perspective, delete the configuration and create a new one. When you delete a configuration, its alerts stop, and the perspective itself does not change.