cost agent flagged a false spend spike - it compared Black Friday traffic against a quiet September baseline
Fixes a cost agent that flags event-driven spend as a spike because it compares Black Friday traffic against a quiet September baseline. Use when seasonal or promotional traffic triggers false spend alerts. Key trigger: the spike lines up with a known traffic event but the baseline month does not include it.
TL;DR: Compare event-driven spend against the same event last year, not against a quiet baseline month. Tag the Black Friday window as a known traffic event and build a separate baseline for it. The detector stops crying wolf every November, and a genuinely wasteful event still alerts.
ANOMALY: November spend $182,400 vs September baseline $41,200 (4.4x) - flagged as spike- Verify the spike is scale, not waste: compare requests or orders against spend for the same window. Expected: cost per request roughly flat. If unit cost jumped, stop here and investigate the inefficiency instead.
- Define the event window with the business calendar: Black Friday through Cyber Monday, adjusted each year. Expected: a dated window stored in the detector config, not in someone's head.
- Build the event baseline from the same event last year, scaled by expected growth. Expected: this year's spend lands within threshold of last year's event.
- Re-run detection with the event window excluded from the normal baseline and scored against the event baseline. Expected: no alert this year; a 2x deviation from last year's event still alerts.
- Calendarize next year's window now, before anyone forgets. Expected: no scramble next November, the window is already in config.
Use this when
- Seasonal or event traffic triggers false spend alerts
- The baseline period does not include the event being measured
- Marketing-driven spikes page FinOps every year
- Your detector models spend over time but not spend per unit of traffic
Not for this skill when
- Cost per request actually rose during the event (real inefficiency, investigate it)
- The spike happened outside any known event (treat it as a real anomaly)
- You have no prior-year data (use the first event to establish the baseline and alert loosely until then)
- The 'event' is just normal growth with no traffic spike behind it
Variant phrasings
- Black Friday cost alert false positive
- seasonal traffic flagged as spend anomaly
- event spend vs quiet baseline
- holiday traffic cost spike alert
Why it happens
Baselines are usually trailing 30 to 90 day averages. A quiet September makes November look insane by comparison. The deeper issue: the detector models spend over time but not spend per unit of traffic, so legitimate scale reads as waste. The business knows November is big; the model does not.
Edge cases
- First Black Friday with no prior year: use the closest big promo as a rough baseline and widen the threshold for year one
- Traffic mix changes break year-over-year comparisons (more GPU inference this year, different product mix): normalize per workload before comparing
- The event running long (a full week of deals) needs the window extended, or the tail end alerts
- Post-event cooldown spend (returns processing, restocking jobs) can trigger a second false alert a week later
- If the event baseline itself was wasteful last year, you are now blessing waste: review the event's unit economics yearly, not just the variance
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_ZnhskPHzEyrG7hP2ajdMtg
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.