## TL;DR
Your continuous profiler aggregates across deploys, so a hot spot from the old build got averaged into the new build's profile and the new code took the blame. Slice every profile by build or deploy ID before comparing. When you compare only same-version windows, the "regression" usually turns out to predate the deploy.

```text
agent's continuous profiler aggregated across deploys and blamed the new code for the old code's hot spot
```

1. Check the window. Look at the time range behind the regression alert and list the deploys inside it. Expected: at least one deploy boundary sits inside the aggregated window.
2. Slice by build. Re-run the analysis segmented by build ID or deploy timestamp: old build's profile versus new build's profile, separately. Expected: the hot spot exists at the same intensity in the old build's slice.
3. Confirm the code did not change there. Check whether the blamed function or its callers actually changed in the deploy. Expected: the hot function is byte-identical across the deploy; only unrelated code shipped.
4. Fix the aggregation. Configure the profiler or its queries to always segment by version, and make regression alerts compare same-version windows only. Expected: future alerts fire only when a hot spot actually appears or grows within one build.

## Use this when
- A performance regression alert fires right after a deploy
- The blamed function did not change in that deploy
- The profile window spans a deploy boundary

## Not for this skill when
- The hot spot is absent from the old build's slice: then the deploy really did introduce it
- There was no deploy near the alert: look at traffic or data changes instead

## Variant phrasings
- "continuous profiler shows regression after deploy but code unchanged"
- "profiler blaming new release for old hotspot"
- "how to compare profiles across deployments correctly"

## Why it happens
Continuous profilers aggregate over time windows, and a window that straddles a deploy mixes samples from two different binaries. Attribution usually keys on function names, which survive the deploy unchanged, so the old build's heat gets smeared onto the new build's timeline right where the alert looks.

## Edge cases
- Rolling deploys mix versions for longer: widen the exclusion zone around the deploy or segment strictly by build ID, not by time
- Function names can collide across versions with different bodies: build ID segmentation handles this, name-based diffing does not
- A real regression can hide inside a mixed window too: always check both slices before dismissing the alert

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wVRSNfbOYZwQJZIl-hH9aw