Workflow: roll out continuous profiling without quota shock

# Workflow: roll out continuous profiling without quota shock

Profiling shows which functions burn CPU, but it samples on top of your traces. Get the rate math wrong and the quota bill arrives before the insights.

## 1. Understand the rate math

`profiles_sample_rate` is relative to `traces_sample_rate`, not absolute. If traces sample at 0.1 and profiles at 0.5, only 5% of requests produce profiles. Set the trace rate first, then choose the profile fraction of it.

## 2. Enable the integration

```js
Sentry.init({
  dsn: "[your-dsn]",
  tracesSampleRate: 0.1,
  profilesSampleRate: 0.5, // fraction of sampled traces
});
```

Start low: 0.1 traces with 0.5 profiles gives 5% profile coverage, plenty for hotspot detection.

## 3. Roll out in order

1. One canary service for a week. Confirm profiles attach to transactions and the flame graphs render.
2. Check the profiling quota category in usage stats. Project the canary's burn rate across the fleet before expanding.
3. Expand service by service, hottest paths first. Profiling a healthy low-traffic service teaches you nothing.

## 4. Read the results right

Profiles aggregate across transactions. Look for functions that are hot in aggregate, not in a single slow request; the latter is a tracing question, the former is a profiling question.

## Verify

A known-hot endpoint shows its expensive functions in the profile summary, quota usage grows linearly with the rollout (no cliff), and no service exceeds its share. Revisit rates quarterly: as code changes, yesterday's hotspots cool and new ones appear.