Cloud Cost Anomaly Detection

import { Steps } from ‘@astrojs/starlight/components’;

Cloud Cost Anomaly Detection

Anomaly detection catches unexpected spend spikes before they compound into a surprise bill. Xplorr monitors every connected cloud account automatically — no configuration needed to get started.

How it works

Xplorr tracks daily spend for every combination of account, service and region. For each one it takes the most recent day with data and compares it with the average of up to 7 days before it. It flags an anomaly when both of these hold:

• the day’s cost is more than 50% above that baseline, and
• the day’s cost is at least $1, or the increase is at least $0.50 (so a $0.01 to $0.02 jump is ignored as noise).

Detection runs every 6 hours (00:00, 06:00, 12:00 and 18:00 UTC). Each account, service, region and day is flagged at most once.

Severity levels

Severity	Spike range	Example
Low	50 to 100% above baseline	$100/day baseline, actual $165
Medium	100 to 200% above baseline	$100/day baseline, actual $250
High	200 to 500% above baseline	$100/day baseline, actual $420
Critical	500% or more above baseline	$100/day baseline, actual $650

Every anomaly is notified as soon as it is detected, whatever its severity. Severity helps you decide what to look at first.

Notification channels

Anomaly alerts go to two places:

• Email: sent to your organization’s active admins, except anyone who turned off cost anomaly alerts on their Profile page
• Slack: posted to your Slack workspace’s default channel through the Xplorr Slack app, or to the organization’s Slack webhook

Each alert includes:

• The service, region and account affected
• The day’s cost against the baseline
• Percentage increase and severity
• The likely cause, with the evidence it is based on and a confidence level (see Anomaly Root Cause)

Why it happened

Each anomaly comes with a root cause: the change in your account’s audit log (CloudTrail, the Azure Activity Log or GCP audit logs) or Kubernetes cluster that most likely caused it, who made it and when, plus for AWS the usage types whose cost rose. Every cause cites its evidence and carries a confidence level of High, Medium or No clear cause. See Anomaly Root Cause for what it reads, the permissions it needs and its limits.

Managing anomalies

Open anomalies from the left sidebar in the console. An anomaly starts as Open, and you can set it to:

• Acknowledged: someone has seen it
• Investigating: someone is working out the cause (answering Investigating also assigns it to you)
• Resolved: the underlying issue is fixed
• Dismissed: not a real problem

Acknowledged and resolved anomalies are deleted 90 days after they were last updated.

Custom alert rules vs automatic detection

Automatic detection works out of the box for all services and accounts. But you can also create custom rules for tighter control:

1. Open Alerts and click Create alert.

2. Pick what to measure: total cost, service cost, daily spend or month end forecast, optionally for one cloud account.

3. Pick the condition and threshold: greater than or less than an amount, or a percent increase.

4. Add email recipients and, optionally, a Slack webhook for this rule.

5. Click Create alert.

Custom rules are evaluated once a day at 08:00 UTC, in addition to automatic detection. The two are independent, so the same spike can produce both an anomaly alert and a rule alert.

Editing a rule

Click a rule in the list to open it, change the scope, threshold or notification channel, and save. An edit re-evaluates the rule against current data immediately, rather than waiting for the next scheduled check.

Testing a rule before you rely on it

Click Send test on any rule to send a real notification through its configured channels (email, Slack, or both) without waiting for it to actually trigger. It confirms delivery is set up correctly, for example that the right Slack channel actually receives the message, while you’re still configuring the rule. Every alert Xplorr sends, including a test, renders in the same branded card layout.

Common mistakes

• Ignoring low-severity anomalies. A small daily increase that persists for a month adds up, and is often a symptom of a misconfiguration that affects other services too.
• Not connecting all accounts. Anomaly detection only works on connected accounts. If your dev account isn’t connected, you won’t catch cost spikes there.
• Treating anomalies as false positives without checking. Month-end batch jobs or auto-scaling events can cause legitimate spikes. Acknowledge them so your team knows they’ve been reviewed, but always verify first.

FAQ

Can I disable anomaly detection for a specific service? Not per service from the console. Each person can turn off anomaly emails on their Profile page.

How quickly will I get notified? Detection runs every 6 hours, on whatever billing data your provider has delivered. Provider billing data itself lags by up to a day or more.

Does it work for Azure and GCP too? Yes. The same 7-day rolling baseline applies to all connected providers.

What if my baseline is $0? It is skipped. A service with no spend in the days before is not compared, so new spend on a brand new service does not raise an anomaly. Use a custom alert rule or a budget to watch for it.

Key takeaways

• Anomaly detection is automatic — it starts working as soon as you connect a cloud account.
• Four severity levels help you prioritize response: focus on critical and high first.
• Combine automatic detection with custom rules for production-critical services where even small spikes matter.
• Acknowledge, resolve or dismiss anomalies to keep the signal clean for your team.