Cloud cost alerts: how to set them up in AAA Sentinel so the bill holds no surprises

The cloud bill surprise always follows the same script: the month closes, the invoice arrives, the number is higher than expected and the investigation begins. By then, the resource that took off has been billing for weeks. Alerts exist to shorten that gap, but they only work if they fire early, reach the right person and come with something concrete to do. In this article we show how to set them up with AAA Sentinel and with each cloud's native budgets, which complement each other.

The problem: one alert, and too late

Many teams have, at most, a notification when the month's spend reaches the budget. By the time it arrives, the month is spent and all that is left is explaining what happened. Others have alerts landing in an inbox nobody reads, or so many alerts that the team has learned to ignore them.

A single alert at 100% of the budget is like a burglar alarm that only goes off once the burglary is over.

What you gain

With alerts spread across layers:

You see a spending spike on the next scan, not on the invoice.
Each alert lands where the team works: email, Slack or your own system.
Whatever needs fixing ends up as a Jira or Linear ticket, with an owner and a priority.
People who do not need the detail get a daily or weekly summary instead of every alert.

First: AAA Sentinel does not replace your cloud budgets

Let us be clear: AAA Sentinel has no cloud budgets. It does not set a monthly cap per account or warn you at 80% of an amount. The budgets it manages are AI budgets, which is a different story. For the monthly cap, use each provider's native budget, which has first-hand billing data. AAA Sentinel adds what a budget cannot see: increases between scans, new findings that explain the increase, per-service anomalies and a single place to alert on all three clouds.

The three-layer strategy

This is the combination we recommend:

Layer 1 · The monthly cap: a native budget in each cloud, with alerts on forecast and actual spend (for example, at 80% forecast and 100% actual). It tells you whether the month is on track to overshoot.
Layer 2 · The deviations: AAA Sentinel's spend spike alert, which compares each scan with the previous one, and the anomalies report, which drills down to each service.
Layer 3 · The causes: alerts for new critical or high-priority findings, which arrive with the specific resource and can open a ticket on their own.

Layer 1: native budgets in each cloud

All three providers solve it in a similar way:

AWS: AWS Budgets, in Billing and Cost Management. Cost budgets by account, service or tag, with alerts on actual or forecast spend via email or Amazon SNS. For unexpected spikes, AWS Cost Anomaly Detection uses machine learning and notifies through the same channels.
Azure: Cost Management → Budgets. By subscription or resource group, with alert conditions on actual or forecast cost that send email or trigger an action group. Cost Management also offers anomaly alerts per subscription.
Google Cloud: Billing → Budgets & alerts. Threshold rules on actual or forecast spend (50, 90 and 100% by default), emailing billing admins, plus Pub/Sub if you want to automate something.

A budget warns; it does not stop spending. If you want an automatic reaction, AWS Budgets has budget actions, Azure can fire an action group, and on Google Cloud you build it from the Pub/Sub message.

How AAA Sentinel alerts work

Alerts are generated on the Pro and Business plans, when each scan of each account finishes. On those plans scans are automatic and daily, so in practice the platform checks each account once a day. This is what can trigger an alert:

AAA Sentinel · what triggers each alert

Spend spikes: The cost recorded by the scan rises against the previous scan by at least the set threshold, and exceeds the minimum spend. High severity, or critical if the increase reaches 50%
New critical findings: The scan brings at least one new finding (or is the account's first): an alert listing the critical findings
New high-priority findings: Same, with the high-priority findings and the savings they add up to
Unit cost increase: Monthly alert if cost per business unit goes up (Business plan, requires business metrics)
New security findings and Security Score drop: Alerts from the security posture scan

Every alert is kept in Alerts for 90 days, whether or not it was sent to a channel.
AI connections use the same switches: an AI spend spike or an AI budget about to run out also arrives as an alert.

Worked example: ACME

ACME, a fictional company on the Pro plan, has three connected accounts: its shop on AWS, an Azure subscription and a Google Cloud project. It wants to hear about any serious increase the same day and have the actionable items end up in Jira. This is its setup:

ACME · alert configuration

Email: On: goes to the address of whoever saves the configuration
Slack: Webhook for the #finops-alerts channel
Spending spike threshold: 25%
Minimum spending to alert: 100 USD/month
Periodic summary: Weekly, Mondays at 07:00 UTC
Jira: FINOPS project, alerts of severity High or above
AWS Budgets (in AWS): 6,000 USD/month, alert at 80% forecast and 100% actual

Step 1: connect the channels

Everything lives in Alerts → Alert channels, which only the owner and admins can change. Each channel has its own test button: use it before trusting anything.

Email: turned on with a switch, it sends to the address that the person saving the configuration uses to sign in to AAA Sentinel.
Slack: at api.slack.com/apps create an app, enable Incoming Webhooks, click "Add New Webhook to Workspace", pick the channel and copy the URL, which starts with hooks.slack.com. Paste it into "Slack Webhook URL" and click "Test webhook".
Microsoft Teams: in the channel, open More options → Workflows, choose the "Send webhook alerts to a channel" template, confirm the team and channel, save and copy the URL. It carries a signature: treat it like a password. URLs from the old Office 365 connectors (webhook.office.com) are rejected, because Microsoft switched them off in May 2026.
Generic webhook: a public HTTPS URL (internal network addresses are rejected) that receives a JSON POST with the type, severity, title, message, account and scan. If you need it signed, the webhooks under Developer → OAuth2 applications emit the alert.triggered event with an X-Sentinel-Signature header.

Step 2: tune the detection thresholds

On the same page, the Detection thresholds block decides when an alert is worth sending:

Spending spike threshold: between 5 and 100%, in steps of 5; 20% by default.
Minimum spending to alert: 0 to 1,000 USD/month; 5 by default. Avoids alerts on nearly empty accounts.
Unit cost increase: between 5 and 100%; 20% by default. Only applies if you use unit cost.
Notify when detected: one switch per type (New critical findings, New high-priority findings, Spend spikes, New security findings, Security Score drop and Unit cost increase). All are on by default.

On AWS, on Azure and on Google Cloud with the billing export, the cost each scan reads is the month-to-date total. So that this natural growth does not look like a spike, AAA Sentinel compares each scan's daily spend rate, projected to the full month, which also keeps the month rollover from looking like a drop. During the first three days of the month there is not enough basis and spikes are not evaluated, and the same happens when one scan uses estimated costs and the other real ones.

Step 3: the periodic summary

Not everyone needs every alert. The Periodic summary is a daily or weekly email (you choose the day of the week and the send time, in UTC) with the latest scan's cost, the findings, the potential savings and how many critical and high alerts there were in the period. It is sent per account, and only if at least one scan completed in that period. ACME schedules it for Mondays at 07:00 UTC for management, and keeps real-time alerts for the platform team.

Step 4: from alert to ticket

On the 14th, the scan of ACME's AWS account records 3,100 USD against 2,400 USD on the previous scan: a 29% increase. As that is above 25% and the 100 USD minimum, a high-severity spend spike fires. Here is what happens next:

The alert reaches the inbox and #finops-alerts, with a link to the platform.
Since Jira is set to severity High or above, a ticket is created in the FINOPS project with the matching priority and the finops-sentinel label. Linear works the same way. Both are configured in Alerts → Integrations, each with a "Test connection" button.
On the Alerts page, the team sees it alongside the rest, can filter by severity or account, and marks it as read once reviewed.
From a specific finding you can also open a ticket by hand, without waiting for any alert.

Step 5: Anomalies, to find out which service did it

A 29% increase says something changed, not what. On the Business plan, Reports → Anomalies compares the last two scans of each account, service by service, and detects four kinds of anomaly:

Account spend spike or drop: more than 15% and more than 5 USD of difference.
New service: a service that was not there and appears with more than 10 USD.
Spike in an existing service: more than 25% and more than 5 USD of increase.
Each anomaly can be marked as reviewed, dismissed or reopened. Dismissed ones do not count towards the Total impact.

These are fixed rules on the comparison between scans, not a machine learning model, and the report is computed when you open it: it does not send alerts. For ACME, it would have shown that almost all of the increase came from Amazon EC2.

What it does not do yet

So you know where the limits are:

It has no cloud budgets and no alerts by percentage of a budget: that is what AWS Budgets, Azure Cost Management budgets and Google Cloud budgets are for.
It does not catch spikes within the day: it compares scan with scan, normally once a day.
Channel and threshold settings are shared across the whole organisation; if you manage clients on the Business plan, each client can have its own.
The anomalies report thresholds are fixed; the ones you set in Detection thresholds only affect alerts.

Checklist to get started

With these pieces in place, the month-end invoice stops being the first warning.

A native budget in each cloud, with alerts on forecast and on actual spend.
Pro or Business plan, with accounts connected and scanned daily.
At least one channel tested in Alert channels: email, Slack or webhook.
Spike threshold and minimum spend tuned to your spend, so every alert means something.
The periodic summary for people who do not need every alert.
Jira or Linear connected in Integrations so that what matters ends up as a ticket.
On Business, the Anomalies report reviewed after every spike.