We are launching a new product on April 10th 2025: Continuous Profiling (backend) and UI Profiling (frontend & mobile). These are major upgrades from our old transaction-based profiler.
TL;DR: Why It Matters
Pinpoints the exact line/function/thread causing performance pain
Helps backend & frontend teams fix issues faster and run leaner
Works with or without tracing (but better together!)
One of the only vendors doing UI profiling in production
Who It's For
Senior devs at companies with large, fast-moving teams
For companies where code complexity is high and performance debugging is painful
For companies where infra cost reduction, user trust, and retention are key priorities
Pricing & Packaging
Continuous Profiling (Backend): $0.03/hr
UI Profiling (Frontend & Mobile): $0.25/hr
No volume discounts
Not included in Dev/Team plans – must be budgeted or prepaid
Billing Examples
Backend: 10 services × 730 hrs × $0.03 = ~$230/mo
Frontend: 10K sessions × 6 min avg × $0.25/hr = ~$250/mo
So per month: 730 * average number of concurrent sessions at any given moment?
Correct. To estimate continuous profiling usage: Monthly Hours = 730 x Avg. Concurrent Sessions, then multiply by the unit cost ($0.03/hr for Continuous Profiling)
Setup Notes
New Session-scoped sampling (not per-transaction)
Profiling can now run independently of Tracing (manual mode), or be tied to traces (trace lifecycle).
No dynamic or server-side sampling at launch.
New startProfiler() / stopProfiler() controls OR automated via tracing
SDKs: Python + Node (backend); iOS + Android (frontend); browser coming soon
Legacy transaction-based profiling remains untouched for AM2 customers
Are there any performance impacts or downsides to implementing profiling?
Yes. We target 5–10% CPU overhead, which is manageable for most apps. For high-throughput or sensitive services, use sampling or limit the number of concurrently profiled instances.
Will Continuous and UI Profiling be available for self-hosted (OSS)?
Yes. It will be available, though may not be included at GA launch. Expect it to follow shortly after.
Why would profiles be rate-limited or dropped?
To protect infrastructure, similar to transaction rate limits. Long-running or high-volume profiles are more likely to be dropped. Rate limits can be adjusted if needed.
Is the estimate of dropped/invalid profile hours more likely to be low or high?
We don’t measure actual durations of dropped profiles (too costly). Estimates are based on average durations (e.g., ~9 seconds/profile), so there's some uncertainty.