Cost Alerts: Budget and Cost Anomaly Monitoring
Overview
Cost Alerts in Spotto help you catch “this is getting expensive” situations early—either because you’re trending toward a budget overrun, or because daily spend suddenly looks abnormal. Each alert is meant to answer two questions quickly: what happened and where to look next.

Cloud provider billing data often arrives with delay. Spotto uses estimation and forecasting to warn earlier during that delay window. Treat alerts as early signals—and validate final numbers against your provider billing exports.
Feature overview
Cost Alerts include three alert types:
- Budget alerts: Track spend against a budget over a defined period and warn when thresholds are crossed. Budget alerts can also include a period-end forecast so you can act before the month ends.
- Early-spend alerts: Detect estimated daily cost impacts and resource create bursts before billing catches up. During validation these appear in the portal without external notifications.
- Cost anomaly alerts: Detect unusual daily spend changes (spikes or sudden shifts) over the last ~30 days and prompt investigation.
Once an alert triggers, you can:
- Acknowledge it (you’ve seen it; you’ll investigate or handle it later).
- Resolve it (you’re done; it shouldn’t keep paging you).
Why use this? (Jobs, pains, gains)
Jobs to be done
- When spend is trending up, I want an early budget risk signal, so I can adjust before month-end.
- When costs jump unexpectedly, I want to pinpoint the drivers, so I can fix the actual cause (not debate the invoice).
- When I manage multiple subscriptions or environments, I want to scope alerts to the part I own, so the signal stays actionable.
Common pains
- You notice overspend only after month-end close (which is… not ideal timing).
- Provider-native alerts can tell you “spend increased”, but not always “what caused it”.
- Teams share subscriptions, tags drift, and you end up paging the wrong people.
What you gain
- Earlier warnings via forecasting and estimation (when billing lags).
- A cost breakdown view that helps you narrow down the likely drivers by subscription, service, and resource.
- A lightweight workflow (Acknowledge/Resolve + notes) so alerts don’t become “that list everyone ignores”.
Key capabilities
Where to find it
In the Spotto Portal, open your company and go to Tasks -> Monitor -> Alerts.
Create alert definitions (the rules)
Alert definitions are the “what to watch” rules. A definition typically includes:
- Type: Budget, Cost anomaly, or Early spend
- Scope: which subscriptions and/or tags the rule applies to
- Trigger conditions: when the alert should fire
- Destinations: where notifications should be sent (email, webhooks, ticketing, chat)
Recommended alerts
On the Cost tab, open Alert Definitions to find Recommended Alerts. Early spend uses the same recommendation card and standard creation flow as the other Cost templates. Its Create action includes the selected Azure subscriptions that are not already covered. If matching rules cover the selection, Configured explains that coverage and Manage opens the existing definitions. Review opens an overlapping or disabled rule so you can inspect its settings before creating another.
On the Generic tab, configured recommendations also remain visible. For example, Credentials and Key Vault objects expiring in 30 days shows Configured when enabled rules cover the selected subscriptions. Existing definitions keep their saved names. To cover more subscriptions, expand the selection and create the recommendation for the uncovered scope.
Early spend appears in the portal during validation without external notifications. Automatic defaults and backfill can enable it even if you have not created a rule manually; check the configured definitions and your company's opt-out setting. Other alert types require a notification destination to deliver notifications.
Default alerts for new companies
After Spotto registers enabled Azure subscriptions, it creates two Cost anomaly defaults and an Early spend default. All cover enabled subscriptions with no tag filter. Existing edited, disabled, deleted, or opted-out defaults remain under your control. Untouched defaults expand when subscriptions are added.
| Default definition | Trigger |
|---|---|
| Day-over-day jump | Billed spend crosses the prior-week and previous-day thresholds with a minimum daily spend increase. |
| Month-over-month jump | Billed spend crosses the prior-week and same-day-last-month thresholds with a minimum daily spend increase. |
| Early spend | The conservative estimated daily increase meets the absolute and percentage thresholds, or a create burst reaches its configured count. |
Cost anomaly defaults notify the Default action group when they open. Early spend remains visible only in the portal during validation. A Budget alert still needs your amount, period, and currency choices.
Early-spend validation
Open Alerts → Cost → Alert Definitions and choose Create Early Spend Alert when there is no Early spend definition. Edit its cost-impact thresholds, burst count and window, optional resource types, and subscription scope. Tag scopes are not supported.
Cost impacts use a one-day estimate in the subscription billing currency and show an Estimated badge, range, confidence and basis. A percentage threshold needs seven complete days of billed spend in the same currency. Without that baseline, cost-impact alerts wait; create bursts can still appear. Percentage zero uses only the absolute threshold. Telemetry run-rate collection belongs to the next phase and is not active.
The detail view shows activity evidence and caller identity, burst sample resources, and billing reconciliation. Cost estimate unavailable means a count-only signal, not zero spend. Delayed or incomplete billing remains pending. Reconciliation uses a settled billed day after the latest signal and the incident's opening baseline. Bursts also wait for 24 hours without matching creates. Resolved incidents stay resolved on replay.
Create bursts count operations with successful creation evidence. The first write Spotto observes may update an existing resource and does not by itself count as a create.
Billed incremental daily spend is billed daily cost minus the pre-change baseline. A negative amount means spending fell below that baseline. The currency code identifies the subscription billing currency. If creation evidence is corrected, reconciliation waits for a reliable baseline and keeps the original estimate available for comparison.
During validation, opening, acknowledging, resolving and escalating Early spend alerts send no external notifications or tickets. Caller identity stays in the portal; external inclusion is an explicit option for the later notification release. Existing Budget and Cost anomaly notifications identify their data basis; estimated chart values use labels and dashed styling.
Early-spend troubleshooting
| Symptom | Cause | Action |
|---|---|---|
| No cost-impact alert yet | Incomplete currency-proven baseline or threshold not met | Check billing, confidence and thresholds. Bursts remain available. |
| Cost estimate unavailable | Some burst resources lack fresh configuration or supported pricing | Wait for another evaluation or billing; inspect the sample resources. |
| Reconciliation stays pending | Incomplete coverage, currency mismatch, or continuing creates | Allow settled billing to arrive; absence alone is not zero billed spend. |
| No external notification | Validation release | Review portal history; delivery needs a later validated release. |
Scope (Subscriptions and Tags)
You can scope an alert to:
- One or more subscriptions, or
- Tags (for example,
env=prod), using:- any: match if a resource has any of the selected tags
- all: match only if a resource has all of the selected tags
Practical tip: if you’re not sure tag coverage is consistent, start with any (or start with subscriptions), then tighten scope once you’ve confirmed the signal is correct.
Triage alerts (History and Details)
From the alerts list, you can filter by:
- Status: open, acknowledged, resolved
- Type: budget, cost anomaly
- Date range (useful for “what happened last week?” investigations)
In the alert details view, you’ll typically see:
- A human-readable summary of what triggered
- A timeline of “first seen / last seen / acknowledged / resolved”
- The original alert definition (when available)
- A cost breakdown to help you locate the likely drivers

Understand spend, estimation, and forecast (without overthinking it)
Cost Alerts may use multiple data sources, depending on what’s available at evaluation time:
- Billing-backed: spend supported by cloud provider billing data. Cost anomaly comparisons use the amortized basis.
- Estimated: best-effort spend estimates used when billing data is delayed or incomplete.
- Blended: a mix of billing-backed + estimated spend (common during delay windows).
- Forecast: projected future spend for the remaining days in the period (used by budget alerts).
Better early estimates for Azure VMs and SQL Databases
Spotto now estimates VM and SQL Database run-rate from the resource configuration (size/SKU, region, disk) and Azure retail pricing, then tunes that estimate with recent billing when it exists. This means alerts and breakdowns include these resources sooner, especially right after a VM/SQL create or resize.
For Last 30 Days budgets, we intentionally don’t show a forecast. That view already represents a complete rolling 30‑day window, so a forecast would just echo the current spend and add noise. Instead, you’ll see a clearer signal based on billing-backed + estimated data only.
If a coverage indicator is shown, treat it as a sanity check:
- Higher coverage usually means the current-period view is based on more complete data.
- Lower coverage means you should treat the result as an early warning (still useful, but not “final invoice”).
How it differs from provider-native alerts
Provider-native tooling can often alert on spend or budgets, but Cost Alerts in Spotto are designed to be:
- More explainable: the alert is paired with a breakdown view so you can move from “we’re over” to “it’s these services/resources”.
- More actionable across scope: you can target subsets via tags and multi-subscription definitions, then route notifications to the right destination.
- More early-warning friendly: forecasting and estimation are used to surface risk earlier when billing is lagging.
Limitations (honest, boring, useful)
- Alerts are not real-time. They depend on successful data refreshes and upstream billing/metrics availability.
- Forecasts are estimates. They’re directionally useful, but you should still validate against billing exports for settlement numbers.
- Tag-scoped alerts are only as good as your tags. If tags are missing or inconsistent, scope accuracy will reflect that.
- Some specialized configurations (for example, serverless SQL or certain disk types) may show a lower-confidence estimate until billing data arrives.
- If Azure snapshots lag after a create/resize, the first alert may show a lightweight placeholder for that resource.
Troubleshooting
A budget alert didn’t trigger, but spend is clearly rising
What you’re seeing: Spend is climbing, but no open budget alert appears.
Likely causes:
- The definition is disabled or scoped to the wrong subscription/tags.
- Thresholds are set too high (for example, only 100%).
- Billing data is lagging, so current spend hasn’t fully landed yet. How to fix:
- Confirm the definition is enabled and scoped correctly.
- Add an earlier warning threshold (for example, 70–80%) if you want lead time.
- Re-check after the next data refresh if you suspect billing lag.
Forecast looks “way too high” (or “way too low”)
What you’re seeing: The projected period-end spend looks unrealistic.
Likely causes:
- Early in the period, there isn’t enough data for a stable trend.
- A recent spike is being extrapolated forward (which might be the point—spikes matter). How to fix:
- Check the breakdown to see whether the forecast is driven by a small set of services/resources.
- Treat forecast as a risk signal, then validate your final numbers with provider billing exports.
An alert has no breakdown available
What you’re seeing: The details view shows no breakdown.
Likely causes:
- Breakdown data isn’t available yet for that instance. How to fix:
- Use the summary as your immediate signal (it’s still actionable).
- If you need deeper triage, validate with provider billing views and check again after a refresh.
Tag-scoped alerts are too quiet (nothing triggers)
What you’re seeing: Alerts scoped by tags rarely trigger, even though you expect activity.
Likely causes:
- Tags aren’t consistently applied (especially with all matching).
- The spend drivers don’t actually carry the tags you selected. How to fix:
- Start with any matching, then tighten to all once tag hygiene is confirmed.
- Validate tag presence on the resources you expect to be in scope.
Some notification details look redacted
What you’re seeing: Destination fields (emails, webhook URLs) appear hidden.
Likely causes:
- You’re not viewing as an administrator, and Spotto redacts secrets by default. How to fix:
- Ask a company administrator to verify the destination configuration.
If you’re still stuck, capture:
- The alert definition name
- A screenshot of the alert summary
- The time range you expected it to trigger
…and send it to your Spotto contact or contact us.