agent set the budget threshold from last month's spend, but last month had a one-time migration spike

TL;DR

Last month is a sample of one, and a migration month is a biased sample. Baseline the budget on the trailing three-month median with one-off spikes excluded, document what you excluded and why, and set the threshold as a percentage above that baseline. Revisit the baseline quarterly or after any known one-off.

agent set the budget threshold from last month's spend, but last month had a one-time migration spike

Use this when

• A budget threshold never fires because it was set from a spike month.
• A budget fires constantly because it was set from an unusually quiet month.
• The threshold-setting logic is "last month plus X percent" with no anomaly handling.

Steps

1. Pull the last 6 months of spend and mark the one-off events: migrations, load tests, launches, incidents. Verify: each anomaly has a known cause, not a guess.
2. Compute the baseline as the median of the clean months (exclude the anomaly months entirely, do not average them in).
3. Set the threshold as a percentage above the baseline (for example, 120%) rather than copying a raw number.
4. Document the excluded months and the reasons alongside the budget so the next reviewer understands the baseline.
5. Create a separate temporary budget for known upcoming one-offs (the next migration) instead of letting them pollute the baseline.
6. Revisit the baseline quarterly; drift is normal and a stale baseline is a quiet lie.

Variant phrasings

budget threshold based on anomalous month

The methodology framing.

aws budget baseline excluding one time spike

The fix phrasing.

budget never fires threshold too high

Symptom-level search.

Compatibility: AWS Budgets and any threshold-based alerting; the baseline math is tool-agnostic.

Why it happens

"Last month" is the easiest baseline to compute, so automation computes it. But last month contained a migration, and the threshold inherited the spike. Now the budget guards a number that will never recur, which is the same as having no budget. Baselines need judgment; medians approximate it.

Edge cases / pitfalls

• Excluding too many months leaves a baseline built on nothing; if most months are anomalous, the spend pattern itself needs attention, not the baseline.
• A median hides genuine growth trends; if spend climbs steadily, use a trend-adjusted baseline rather than a flat median.
• Temporary budgets for one-offs must have end dates, or they become permanent noise.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_G3iUsAibq1FZrkzD5Li-EQ