Alert rules

An alert rule describes what CloudQuell should watch, how often, and where to send a notification when the condition is met. You manage rules on the Alerting page (in the sidebar under Insights).

What a rule contains

Each rule captures:

Type — trend, anomaly, budget, or expiry (commitment expiry).
Target — what the rule evaluates: your entire organization (combined spend across every connected provider) or a single integration.
Cadence and thresholds — how often the condition is evaluated and the values that trip it. Money thresholds are interpreted in your organization’s display currency; spend is converted into it before the comparison.
Scope — the services, accounts, or tag key/value the rule watches within its target (leave empty to watch everything).
Channels — the notification channels that receive a firing. A rule can deliver to several channels at once: up to one each of email, Slack, and Teams.

Creating a rule

On the Alerting page, select + New Alert Rule and work through the form:

Rule name — how the rule appears in the list and in notifications.
Applies to — leave it on Entire organization to evaluate combined spend across every connected provider, or pick one integration to watch only that provider’s data. The scope pickers below (services, accounts, tag keys) follow whichever target you choose, and switching the target clears any scope selections you’d already made.
Alert type — what condition is checked:
- Trend Spike — fires when total spend for the rule’s scope rises by at least your percentage versus the previous period (day-over-day, week-over-week, or month-over-month).
- Anomaly Scan — compares each service to its own baseline (the average of its four prior windows) and fires per service that rises by at least your percentage and meets a minimum dollar impact, so small-dollar noise doesn’t page you.
- Spend Threshold — fires when total spend for the analysis period reaches a fixed amount. This is a standalone rule; it is not linked to budgets on the Budgets page.
- Commitment Expiry — fires when a Reserved Instance or Savings Plan in scope expires within your notice window (1–365 days).
Check frequency — how often the rule is evaluated: daily, weekly, or monthly. See When rules are evaluated.
Analysis period — the comparison window for trend and anomaly rules, or the spend window for threshold rules. Expiry rules don’t have one — only the days-notice value matters.
Scope (optional) — narrow the rule to specific services, accounts, or a tag key/value. Empty means everything under the rule’s target, and the form summarizes exactly what you’re monitoring as you pick.
Notification channels — attach at least one channel. You can combine types (email + Slack + Teams), with up to one channel of each type per rule; picking a second channel of the same type replaces the first. If the list is empty, an Admin needs to create a channel first.

Save the rule and it appears in the list immediately, active by default.

When rules are evaluated

Rules run on a fixed schedule by frequency — daily rules every day at 08:00 UTC, weekly rules Mondays at 08:00 UTC, and monthly rules on the 1st at 08:00 UTC. When a rule’s condition is met, the firing is delivered to its attached channels and recorded in the firing history.

Pausing, muting, and deleting a rule

Each rule card on the Alerting page carries its controls:

Pause / Resume — a paused rule is skipped by evaluation entirely; resume it to pick the schedule back up. Rules also pause automatically when every email recipient has unsubscribed and no Slack or Teams channel remains — the card shows “Paused — recipients unsubscribed”.
Stop emailing just me — the bell icon unsubscribes your own address from that one rule without affecting other recipients (any role can do this). Click it again to re-subscribe. The same per-rule toggles also live under Notification preferences in the account menu. Recipients outside your organization can do the same via the unsubscribe link in the email itself.
Edit — change any part of the rule, including its target, scope, and channels.
Delete — removes the rule permanently; its past firings remain in the history feed.

Inspecting your rules

You can list every configured rule to see its type, cadence, thresholds, watched services and accounts, and attached channels, or pull a single rule by its id to review it in detail. An empty list is normal — it simply means no rules are configured yet.

An agent connected through the MCP server reads these with list_alert_rules and get_alert_rule, so you can ask “what alert rules do we have and what do they watch?” in plain language.

Firing history

Separately from the rule definitions, CloudQuell keeps a history of every alert that has actually fired. This one feed combines cost-rule firings and budget-threshold crossings, and for each entry records:

The subject and alert type.
When it fired.
The trigger value versus its baseline.
Delivery status — whether the notification was delivered, failed, or suppressed.

You can narrow the history by date or by delivery status to confirm alerts are reaching your channels. Via MCP this is list_triggered_alerts.

Alerts overview — the alert types and how delivery works.
Notification channels — create and test the destinations rules deliver to.
Budget status — where budget-threshold crossings originate.