Workflow: roll out continuous profiling without quota shock

TL;DR

Set the trace rate first, then choose the profile fraction of it. Check the profiling quota category in usage stats.

Steps

1. 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.

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

2. Start low: 0.1 traces with 0.5 profiles gives 5% profile coverage, plenty for hotspot detection.
3. 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.

When to use

You are seeing this: Profiling shows which functions burn CPU, but it samples on top of your traces. Use this skill when you run into "Workflow: roll out continuous profiling without quota shock".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Researched against live Sentry docs 2026-09-26. The JS profiling page (docs.sentry.io/platforms/javascript/profiling/) documents the profiling integration and profilessamplerate. The Ruby guide (docs.sentry.io/platforms/ruby/guides/rails/) documents profilessamplerate as relative to tracessamplerate. The Python options page documents the tracing options model. The quotas page (docs.sentry.io/pricing/quotas/) documents per-category quotas.