Dash0 said on that it had acquired Polar Signals, adding a team and technology for continuous profiling across CPU, memory and GPU workloads. Polar Signals said its cloud product, customer data and support do not change today. The integration is therefore announced, not complete: native profiling in SignalStore, the Great Lakes storage migration and profiling-driven Auto-Tune work remain future steps. Financial terms were not disclosed.
For finance systems and FinOps leaders, the new decision is not whether profiling can expose resource-heavy code. It can. The decision is whether those samples may enter governed cost allocation and whether an AI-proposed fix may enter the change process without weakening approval, testing or savings evidence. The companies have not published an allocation method, migration-control design or measured customer savings. The deal creates a useful usage signal, not an accounting-grade cost ledger by itself.
What changed and what it means
Using ungoverned profiling data or AI-generated code changes could misallocate shared infrastructure cost, break metric continuity and overstate savings.
- Decision affected
- Decide whether continuous-profiling records may enter governed infrastructure-cost allocation and what approval, testing, rollback and savings evidence is required before profiling-driven pull requests are merged.
- Evidence in brief
- Dash0 and Polar Signals say the team, profiler, Great Lakes and Parca are joining Dash0; native profiling, storage migration and Auto-Tune integration remain planned.
- What remains unresolved
- The sources do not define the authoritative allocation record, shared-cost formula, migration acceptance criteria, approval matrix or verified savings baseline.
- Next verification
- Require versioned identifiers, billing reconciliation, named human approval, test and rollback records, and normalized pre/post measurement before financial reliance.
Key takeaways
- Dash0 announced the Polar Signals acquisition on 17 August 2026, while Polar Signals Cloud remains unchanged for customers today.
- Continuous profiling can locate CPU, memory and GPU consumption at code level, but finance still needs billing reconciliation, ownership metadata and shared-cost rules.
- OpenTelemetry Profiles is currently an Alpha specification, increasing the need to version schemas and metric definitions through the planned storage migration.
- Dash0 says Auto-Tune will open pull requests and leave the merge to a human; approval, tests, rollback evidence and normalized savings checks still need named owners.
What Dash0 acquired, and what remains planned
The acquisition brings Polar Signals’ profiler, Parca, Great Lakes and its engineering team into Dash0. Before the deal, Dash0 had connected metrics, logs and traces but lacked the signal showing what code was doing. Polar Signals had developed that signal and its storage technology.
The immediate customer state is narrower than the product vision. Polar Signals says its cloud service, data, user interface, support and Parca maintenance continue as before. Over the coming months, the companies plan to make profiling native in Dash0 and to place Great Lakes beneath SignalStore, replacing ClickHouse over time. Dash0’s current home page also labels Auto-Tune and profiles in SignalStore as coming soon. That makes this a company-announced acquisition with integration pending, not evidence that a new allocation or automated-change control system is already operating.
Profiling is a usage signal, not the cost ledger
OpenTelemetry defines a profile as sampled stack traces with associated values that represent resource consumption and code execution. Its Profiles specification is currently Alpha. The data can be linked to logs, metrics and traces through resource context, but a sample still records technical consumption rather than a currency amount, cost-center owner or approved allocation rule.
Dash0 also documents a Track Cost view for AI coding spend. It computes cost from token counts and a maintained pricing catalog, including API-equivalent estimates for flat-rate seats. That is a separate cost object and measurement basis from infrastructure cost attributed through profiles.
The FinOps Foundation’s allocation guidance allows observability or utilization data to add granularity to cost allocation. It also requires an allocation strategy, a metadata strategy and a shared-cost strategy. In practice, finance needs a controlled join between the source cost and the profiling driver:
| Layer | Authoritative input | Evidence finance should retain |
|---|---|---|
| Billed cost | Cloud bill, invoice or approved internal cost pool | Period, currency, discounts, commitments and total cost |
| Workload identity | Resource, service, environment and code version | Complete identifiers, owner mapping and change history |
| Profile usage | Raw samples, sample type, collector and time window | Immutable source, completeness checks and retention record |
| Allocation rule | Direct and shared-cost drivers | Versioned formula, approval, exceptions and effective date |
| Finance output | Cost by service, product, team or cost center | Allocated plus unallocated cost reconciles to the source total |
Six controls before code-level cost attribution
1. Set the authoritative profiling record
Name the raw profile dataset that controls each allocation run. Record the collector and schema version, sample type, sampling interval, service and environment identifiers, code build, time zone, retention period and correction status. Transformations should be reproducible, with the original profile preserved. A dashboard view should not become the source of record merely because it is easier to read.
2. Reconcile profiling usage to billed infrastructure cost
CPU, memory and GPU samples do not equal money. The allocation pipeline must tie each driver to the same resource pool and billing period as the cost being spread. It must also explain idle capacity, shared platforms, network and support charges, reservations, discounts and commitment benefits. The allocated and unallocated outputs should reconcile to the source bill or approved cost pool, with exceptions routed to a named owner.
3. Version definitions through the storage migration
Great Lakes is planned to replace ClickHouse over time. Before a cutover affects finance reporting, run old and new queries in parallel, document transformations, set tolerance thresholds and obtain sign-off for differences. Version the profile schema, semantic attributes, queries and allocation rules together. The Alpha status of OpenTelemetry Profiles makes this control more important because the underlying standard may still change.
4. Separate recommendation, approval and merge
Dash0 says Auto-Tune analyzes profiling data and opens a pull request; a human still reviews and merges it. The control design should name who may configure the routine, who reviews the evidence and who approves the merge for each risk class. Agent credentials should not approve their own output. The same boundary is central to Finance Circuit’s guidance on finance AI approval and evidence controls.
5. Retain tests and rollback evidence
Each proposed change should carry the profile evidence that triggered it, the exact commit, affected services and expected benefit. The approval pack should include unit, integration, performance and security results where relevant, plus deployment steps, rollback conditions and the observation window after release. A successful merge is not proof that the change was safe in production or that the expected saving occurred.
6. Verify savings against a normalized baseline
Compare equivalent workloads, traffic, environments, code versions and prices before and after the change. Separate lower technical consumption from lower invoice cost because commitments or fixed capacity can delay the financial effect. Record the baseline window, adjustment method, owner, confidence limit and rebound effects. Finance or FinOps should approve a realized-savings claim only after the result reconciles to the relevant cost pool.
What finance systems leaders should require next
- A profiling data contract that identifies authoritative fields, versions, lineage, retention and correction handling.
- An allocation rulebook that maps technical drivers to cost objects and documents direct, shared and unallocated cost.
- A migration acceptance pack with parallel-run results, tolerances, query reconciliation and signed cutover ownership.
- A change-control matrix for configuration, recommendation, review, merge, deployment and rollback duties.
- A benefit-measurement protocol that separates resource reduction, invoice impact and approved realized savings.
These are requirements to set before the planned integration reaches production. They are not claims that Dash0 or Polar Signals currently provides the full control set.
Next evidence to watch
The useful update triggers are native-profiling availability and documentation, a disclosed Great Lakes migration milestone, Auto-Tune control and audit settings, and a customer result with a normalized before-and-after cost test. Until that evidence appears, finance should treat code-level profiles as a decision-support input rather than stand-alone proof of cost allocation or savings.
