Detection

How CostPulse decides to alert

Every rule the detector applies, with the numbers it uses. The numbers on this page are generated from the detection code and the production configuration at build time, and a test fails the build if the code changes without this page. There is no model and no hidden score: if a day's spend meets the rules below, you get an alert, and if it does not, you don't.

The rules at a glance

Baselineaverage of the previous 7 days
Default spike threshold20% above baseline
Spike dollar floorat least $1 above baseline
Critical50% or more above baseline
Weekday checksame weekday, previous 4 weeks, at least 2 samples
Month start (1st and 2nd)threshold × 2
New spend, no history$25 or more in a day, unseen for 35 days
New spend, critical$100 or more in a day (4 × the floor)
History loaded at connect90 days from Cost Explorer
History scan at connectthe most recent 30 days
Day judged when23 of 24 hours of billing data are in, or after waiting 18 hours

Dollar amounts are in your account's billing currency. Percentages are always measured against the 7-day baseline.

What gets judged

One number per AWS service, per region, per connected account: that service's total spend in that region for one day, from your Cost and Usage Report (or Cost Explorer, before the first report arrives). Detection runs once a day, at the hour and timezone you pick in Settings, and judges the previous day.

AWS delivers billing data for a day over many hours. If, at your delivery hour, fewer than 23 of the day's 24 hours of data have arrived (and AWS has not yet moved on to the next day for that account), the detector waits and checks again each hour. After 18 hours it judges the day anyway rather than skip it. Every alert says how many hours of data it was judged on, and a partial day is labelled as such.

Each service and region is judged on its own. A spike in EC2 in us-east-1 is not diluted by the rest of the bill, and a quiet service cannot hide a loud one.

The baseline

The baseline is the average of the daily amounts recorded for that service and region over the 7 days before the day being judged. The judged day itself is never part of its own baseline.

AWS writes no record for a day a service cost nothing. Once your account's data reaches back over the whole window (it has spend on the window's first day), a day with no record for that service and region counts as zero, so spend that starts small and grows is judged against the quiet days before it. Until the data reaches back that far, the average is over the days that have spend, which can only mean fewer alerts, never more.

The spike rule

A day alerts when its spend is at least the threshold above the baseline, and the increase is at least $1. The dollar floor stops a percentage firing on series that cost cents. The default threshold is 20%. You can change it in Settings, and a per-service threshold, where you have set one, replaces it for that service only.

Severity: an alert is critical when the day is 50% or more above its baseline, and a warning otherwise. Every alert states the threshold it was actually judged against, including the month-start adjustment below.

Two checks that stop routine patterns alerting

Weekday pattern. Many workloads are busier on weekdays than at weekends, so every Monday looks like a spike against a 7-day average that includes a quiet weekend. When CostPulse has at least 2 same-weekday days of history from the previous 4 weeks, a spike must also clear the average of those same weekdays by the same threshold. With less history than that, this check stands down rather than suppressing alerts on a guess.

Month start. On the 1st and 2nd of each month, AWS posts once-a-month charges (Reserved Instance and Savings Plans fees, support, other monthly line items) that a daily baseline reads as spikes. On those days the threshold is multiplied by 2, so the default becomes 40%. The bar is raised, not removed: a genuine runaway still alerts, and the alert shows the raised threshold it cleared.

When either check stops an alert that the plain threshold would have sent, the detector logs the reason, so "why wasn't I alerted?" has a specific answer.

Spend with no history

A service and region with no baseline (a region nobody uses lighting up, a service you have never run) has no percentage to judge. It is judged by a separate rule instead, and alerts only when all three of these hold:

  • The day's spend is at least $25. Below that, nothing.
  • That service and region had no spend at all in the previous 35 days. Monthly charges that appear once a month are recurring, not new, and this window covers a full month.
  • The account's data reaches back 35 days. Until it does, such as on the day you connect, every service would look new, so this rule waits rather than flooding you.

New spend of $100 or more in a day (4 times the floor) is critical. Per-service percentage thresholds do not apply here, because there is no baseline to be a percentage of.

When you first connect

CostPulse loads up to 90 days of daily spend from Cost Explorer, so detection works before the first Cost and Usage Report file arrives. It then runs the same rules over the most recent 30 days of that history and shows what it would have caught on your dashboard, labelled as a history scan. Those are not sent to Slack, Teams or email.

What does not change the decision

  • AWS list-price changes. Alerts can say whether a spike lines up with a published price change, but that context is added after the decision. The detector never reads it.
  • Muting. Muting a service and region stops its alerts for the mute period. Its spend is still recorded and judged, so there is no gap in its baseline when the mute ends.
  • Forecasts. CostPulse compares each day with recent days. It does not predict spend or score it with a trained model.

More detail

See the live demo for real alerts on a synthetic account, IAM permissions for exactly what CostPulse can read, and support if a decision looks wrong to you.