TELELENS Waste Report
TELELENS

Your SigNoz bill, itemised: 12.5 GB/mo of waste found read-only — and the fix is proven to drop zero error traces before you apply it.

The findings ↓ GitHub ↗

Statement summary

Error traces kept · SAFE
110,430 / 110,430
Traces ≥ 750 ms kept
145 / 145
Boring traces dropped
−94.9%
Total span volume — errors kept in full
−6.9%
Waste found across 26 findings
12.5 GB/mo

The tool

TELELENS is a read-only profiler you point at your own SigNoz: it prices your telemetry waste in GB and dollars, proves a sampling fix drops zero error traces by replaying it over your real traces, and writes the collector config for a human to review.

This page

This is one real scan's output, rendered as the bill it is — 26 findings from a 7-day window of our demo instance, every figure straight from the scan artifact, nothing applied to the cluster.

What to do here

Move the policy controls further down and the numbers move with them — every position is a recorded replay, not an estimate — then run it against your own instance with one command from GitHub ↗.

How this report happened

  1. 01SCAN
    8.7s
    read-only ClickHouse SELECTs + SigNoz GETs. Nothing written.
  2. 02PRICE
    26 findings
    each one costed in GB/mo and $/mo, not just listed.
  3. 03PROVE
    168,711 traces
    the fix replayed over every real trace → verdict SAFE.
  4. 04GENERATE
    3 processors
    collector config written as a proposal — 0 applied by TELELENS.

That 8.7 s is aggregates, not a row scan: day-sliced GROUP BY queries with top-N limits, and attribute cardinality from ClickHouse's uniqCombined — an approximate distinct count, so cardinality figures are estimates. The safety replay is exact: its input is one row per trace, GROUP BY trace_id across the whole window.

TELELENS never applies anything. It proves, you decide. When a human did apply it, one of the three generated processors was rejected on review — that step is the product.

Telemetry statement · demo SigNoz instance READ-ONLY SCAN · NOTHING APPLIED

Telemetry waste report

A read-only scan of our demo SigNoz instance — every finding priced from the scan artifact, the headline fix proven safe before it is applied.

Scanned2026-07-18T06:08:02.230961Z
Sourceclickhouse (http://localhost:8123, window=7d)
Scan duration8.7s
Pricing basis$0.3 / uncompressed-ingest GB

Total identified savings

12.5 GB/mo
≈ $3.75 / mo
8
high severity
13
medium severity
5
low / directional
Meter read · F-001
−95%
tail sampling

Kept in full — never sampled

Error traces
110,430 / 110,430
Traces ≥ 750 ms
145 / 145

A policy that would lose one of either exits non-zero before anything is generated.

Only then the reduction: 94.9% of “boring” traces dropped

Keep 100% of errors, keep every trace ≥ 750 ms, sample the remaining successful/fast traces at 5%. Of 58,136 boring traces, only 2,947 are kept.

The honest counterweight: dropping 95% of boring traces is not the same as dropping 95% of the bill. Because errors and slow traces are retained in full, total span volume falls by only 6.9% (8,953,804 → 8,332,657 spans). And this window is an error-storm day — 65.5% of its traces carry an error; on a healthy week (~0.04% errors) the same policy drops ~95% of span volume. Safety first, savings second — the profiler never conflates the two.

Sampling safety proof

telelens simulate — replayed on the real scan
✓ Verdict: SAFE keep errors + keep ≥ 750 ms + sample 5% of the rest
110,430 / 110,430
error traces kept (100%)
145 / 145
slow traces kept (100%)
2,947 / 58,136
boring traces kept (5.1%)
113,522 / 168,711
traces kept overall

Replay of 168,711 traces / 8,953,804 spans. The policy is judged SAFE because it retains 100% of error traces and 100% of slow traces — the two classes you actually page on.

Try the policy yourself

every position is a recorded replay, not an interpolation
Keep error traces ON — locked

The profiler refuses to drop errors — non-negotiable. A policy that would lose one error trace exits non-zero.

Slow-trace threshold

Only the three thresholds this window's replay actually covers.

✓ VERDICT: SAFE keep errors + keep ≥ 750 ms + sample 5% of the rest
110,430 / 110,430
error traces kept (100%)
145 / 145
slow traces kept (100%)
2,947 / 58,136
boring traces kept (5.1%)
113,522 / 168,711
traces kept overall (67.3%)
−6.9%
est. span-volume reduction

The honest counterweight: dropping 94.9% of boring traces cuts span volume by only 6.9% — 65% of this window's traces carry an error, and the policy keeps every one of them.

Recomputed from the recorded replay of 168,711 real traces / 8,953,804 spans (assets/live-findings.json, scan of 2026-07-18). The 21 policy positions offered here were each replayed through the same simulator that produced the verdict above; the shipped default (750 ms / 5%) reproduces that record exactly.

All findings

26 total, priced against the scan window
#SevCategoryFinding GB/mo$/mo
F-001Hightraces7801417 near-identical success spans are prime tail-sampling candidates9.7$2.90
F-003Highmetrics86 more metrics are written but read by no dashboard or alert0.3$0.08
F-004HighmetricsMetric "signoz_latency.bucket" is written but read by no dashboard or alert0.3$0.08
F-006HighmetricsMetric "http.server.duration.bucket" is written but read by no dashboard or alert0.0$0.01
F-007HighmetricsMetric "http.server.response.size.bucket" is written but read by no dashboard or alert0.0$0.01
F-008HighmetricsMetric "checkout.cart.value.bucket" is written but read by no dashboard or alert0.0$0.01
F-009HighmetricsMetric "otel.sdk.metric_reader.collection.duration.bucket" is written but read by no dashboard or alert0.0$0.01
F-024HighmetricsUnbounded ID "session.id" is a metric label on browser.sessions.count
F-002MediumlogsINFO firehose: checkout is 35% of your log volume1.9$0.58
F-010MediumtracesSpan attribute "url.full" has 57315 distinct values0.0$0.01
F-011MediumtracesSpan attribute "db.statement" has 54630 distinct values0.0$0.00
F-012MediumtracesSpan attribute "shipping.tracking.id" has 53051 distinct values0.0$0.00
F-013MediumtracesSpan attribute "payment.transaction.id" has 53243 distinct values0.0$0.00
F-014MediumtracesSpan attribute "app.shipping.tracking.id" has 53045 distinct values0.0$0.00
F-015MediumtracesSpan attribute "app.payment.transaction.id" has 53062 distinct values0.0$0.00
F-016MediumtracesSpan attribute "app.order.id" has 65591 distinct values0.0$0.00
F-017MediumtracesSpan attribute "http.url" has 10068 distinct values0.0$0.00
F-018MediumtracesSpan attribute "order.id" has 68176 distinct values0.0$0.00
F-019MediumtracesSpan attribute "app.email.message_id" has 54780 distinct values0.0$0.00
F-020MediumtracesSpan attribute "app.email.recipient" has 10011 distinct values0.0$0.00
F-021MediumtracesSpan attribute "app.user.id" has 43377 distinct values0.0$0.00
F-005LowtracesBrowser RUM telemetry bill: "browser-frontend" ships 120358 session spans across 1 sessions0.2$0.05
F-022LowtracesBrowser RUM telemetry bill: "meridian-web" ships 223 session spans across 38 sessions0.0$0.00
F-023LowtracesAI-agent telemetry bill: "argus" ships 35 gen_ai spans (204665 tokens tracked)0.0$0.00
F-025LowqualityCardinality discipline held: 2 unbounded ID attribute(s) stay off metric labels
F-026Lowqualitydemo-app mixes severity casing ("Info")
Total identified savings · 26 findings 12.5$3.75

Estimates are uncompressed-ingest figures extrapolated from the scan window; findings shown as “—” are directional (cardinality / quality risks that are not reliably priceable). TELELENS profilers are read-only — nothing is applied without a human running foundryctl cast.