On May 12, 2026, InfoQ published Grafana’s Pyroscope 2.0 Makes Continuous Profiling Practical at Scale, reporting that Pyroscope 2.0 achieved "continuous profiling that remains lightweight even when running full-time in production."
Across our client operations projects to date, low-reproducibility performance issues such as "CPU pegged at 100%," "memory leaks rendering scale-out ineffective," and "slower than last month despite having the same instance count" have occurred frequently. Continuous profiling provides a mechanism to record "when / which function / consumed what" at the code level + in time series, serving as direct justification for compressing cloud costs by 20% to 40%. This can be framed as a generalized version of the engineering philosophy of "striking hotspots based on actual measurements" covered in 75% API Cost Reduction with Local-First AI Inference.
Why "logs + metrics + traces" alone are not enough
| Observation target | Existing stack | Unsolvable problems |
|---|---|---|
| Errors | Logs + Sentry | OK |
| Response time | Metrics + Grafana | OK |
| Request paths | Distributed tracing | OK |
| CPU / Memory hotspots | No sampling | Unknown "which function is slow" |
| Intermittent leaks | Snapshot-based | Cannot reproduce |
The three pillars (Logs, Metrics, Traces) tell you "what happened" and "where things are slow," but "which line of code consumed CPU" can only be pinpointed through continuous profiling. This stands as a fourth pillar, adding "Profiling" to the three pillars discussed in OpenTelemetry × Airbnb Observability Migration.
Three innovations of Pyroscope 2.0
Innovation 1: eBPF sampling enables "resident deployment in production"
Pyroscope 2.0 leverages eBPF to perform always-on profiling with 0.5% to 1.5% CPU overhead without application modification. This resolves the traditional barrier of "being unable to run in production due to heavy overhead."
Innovation 2: Linking "commit diffs" with flame graphs
By linking Git commit hashes with flame graphs, regression analyses showing that "CPU usage for function X increased 2.4× since that release" become possible in a few clicks.
Innovation 3: Correlation with OpenTelemetry traces
Profile IDs are linked to OTel spans, enabling you to inspect "slow trace → hotspot of the function running during that span" in a single action. This achieves a vertical drill-down of "metrics → traces → profiles."
Four implementation phases built in custom development
Phase 1: Cost assessment (2 weeks)
By measuring "instance costs versus actual CPU utilization" using Cost Explorer alongside CloudWatch or Datadog, you can present the client with the "actual monetary value of overprovisioning." This establishes the foundation for your ROI estimates.
Phase 2: Pyroscope implementation (3 weeks)
We select between Pyroscope OSS / Grafana Cloud Profiles and deploy to production + staging. We proceed on the premise of zero application modifications via eBPF sampling.
Phase 3: Hotspot remediation loop (8 weeks)
We identify 3 to 5 hotspots per month using commit diffs + flame graphs, executing in two-week loops of code review → fix → production deployment → impact measurement.
Phase 4: Ongoing operations + monthly reporting (Operations)
We report the top 10 hotspots monthly to clients, tracking "infrastructure cost reductions" and "response time improvements" via KPIs. This is the observability version of continuous improvement covered in DORA / SPACE / Core 4 ROI Client Engagements.
Standard technology stack set for custom development
| Layer | Recommended technology | Alternative |
|---|---|---|
| Profiler | Pyroscope 2.0 + eBPF | Parca / Polar Signals |
| Visualization | Grafana Cloud Profiles | Pyroscope OSS UI |
| OTel integration | OpenTelemetry Collector | Tempo + Pyroscope |
| Cost analysis | AWS Cost Explorer + CUR | GCP Billing Export |
| Alerting | Grafana Alerting | PagerDuty |
| Remediation management | Jira / Linear | GitHub Projects |
| CI integration | GitHub Actions + profile diffs | GitLab CI |
In particular, per-commit CPU function diffs, when shown during PR reviews, let you detect worsening hotspots before merging. It is worth incorporating this into CI alongside GitHub Agentic Workflows.
Which projects it fits best
| Suited projects | Benefit |
|---|---|
| SaaS with monthly infrastructure costs exceeding 1,000,000 yen | 200,000 to 400,000 yen monthly savings with 20% to 40% reduction |
| High-load Node.js / Go APIs | GC / Event loop optimization |
| Python / Ruby batch processing | Speedups via hotspot visualization |
| E-commerce / Inventory end-of-month peaks | Peak-time hotspot analysis |
| Gaming / Real-time streaming | Millisecond-by-millisecond latency improvements |
Five clauses to include in custom development contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Reduction target SLA | Target reduction rate for monthly infrastructure costs | Measures upon non-attainment |
| Allowable overhead threshold | Additional production CPU load | Allowable business impact |
| Retention period | Profile data retention period | Storage costs |
| Remediation scope | Demarcation of responsibility for code fixes | Client side / Contractor side |
| Commit integration | Scope of Git access privileges | Compliance |
Four common pitfalls
Pitfall 1: "Deploying across all services all at once"
Deploying simultaneously across all services makes the scope of overhead measurement too broad, causing anomaly detection to fail. The rule of thumb is phased rollout one service at a time.
Pitfall 2: Chasing hotspots without measuring impact
Cases frequently occur where teams "think they fixed it," yet the production flame graphs show no change. Make before/after flame graph comparisons a mandatory item in fix reviews.
Pitfall 3: Underestimating profile data storage costs
One service accumulates 50 to 100 GB of profiles in a single month. Design hot/warm/cold tiered storage from the outset.
Pitfall 4: Defining improvement KPIs solely around "speed"
If you agree only on "improving response times by 20%," you overlook side effects such as "increased storage costs." Align on composite KPIs balancing "speed × infrastructure spend × error rate."
Summary — From "three pillars" to "four pillars"
Pyroscope 2.0 marks a turning point that elevates continuous profiling into the practical realm of "resident deployment in production," establishing four-pillar observability spanning Logs / Metrics / Traces / Profiles as the enterprise standard. A 20% to 40% reduction in cloud costs represents the most reproducible area of self-funding continuous improvement ROI.
However, how far to erect this fourth pillar varies by project. Whether you want to "measure the actual cost of overprovisioning just once" or "run a continuous hotspot improvement loop" demands entirely different timeframes and team structures, and the assumptions for eBPF sampling shift depending on the number of target services and the runtimes (Node.js, Go, Python, Ruby) involved. Even if you are still at the stage of being unable to read your cloud cost breakdown or simply looking to gauge potential cost reductions, please feel free to reach out. Once we understand your environment and premises, we can discuss the best way forward — get in touch via our inquiry form.
Sources
- Grafana’s Pyroscope 2.0 Makes Continuous Profiling Practical at Scale（InfoQ）
- OpenTelemetry × Airbnb Observability Migration (GH Media)
- 75% API Cost Reduction with Local-First AI Inference (GH Media)
- DORA / SPACE / Core 4 ROI Custom Development (GH Media)
- Langfuse AI Development Observability Guide (GH Media)
