// you are…
content adapts, same page
Self-hosted single binary · OpenTelemetry · Open source AGPL-3.0

Spot the wasted I/O in your traces. Price it in energy and carbon.

perf-sentinel catches N+1s, redundant calls, slow queries and fanout in your OpenTelemetry traces, as a CI quality gate or an OTLP daemon, then turns every avoidable I/O into energy and CO₂.

open ↗
HTML report or TUI, whichever you prefer.
Read this first

Prerequisite: your services emit OpenTelemetry traces (SQL, HTTP and messaging spans), or dd-trace bridged through a Collector, carrying the query text (db.statement / db.query.text), the target URL (http.url / url.full) or the broker destination (messaging.system / messaging.destination.name). Setup by language (Java, C#, Rust, Go, Node.js, Python, Ruby, PHP). No OpenTelemetry SDK? Teams on Datadog bridge dd-trace through the Collector datadogreceiver, see Coming from Datadog.

Audit your tracing first: spans that lack those attributes are dropped silently, with no warning, so a thin or empty report can mean no problems found or no usable instrumentation. perf-sentinel inspect shows what was actually extracted, an empty span tree means the carrying attributes are missing upstream. See what bounds the findings.

What it is not: a full APM, a continuous profiler, nor (for now) a standalone regulatory carbon accounting platform. See the comparison.

Maturity: beta, pre-1.0. The CLI, config keys and on-disk formats may still change before 1.0. The JSON output enums are the one part under an explicit stability contract, with breaking changes flagged in the release notes.

// the problem

Why perf-sentinel?

I/O anti-patterns hit any app, monolith or microservices. In distributed systems a request cascades across services and nobody sees the full path.

Existing tools each cover a slice: Hypersistence is JPA-only, Datadog and New Relic are heavy proprietary agents, Sentry is tied to its SDK. None is a protocol-level detector you can self-host and run as a CI gate or an OTLP daemon.

perf-sentinel reads the traces your app already emits (SQL, HTTP, broker publishes), whatever the language or ORM: it sees the queries they generate, without needing to know JPA or EF Core.

Each avoidable I/O is also priced in energy and CO₂, bottom-up and attributable to the code.

// the blind spot

The carbon weight of digital,
and the blind spot no one measures

Digital already accounts for 1.8% to 3.9% of global greenhouse-gas emissions, on par with civil aviation and growing fast. But the share driven by bloated, poorly optimized code and web apps stays unquantified at scale.

Digital is 1.8% to 3.9% of global GHG
5 %4 %3 %2 %1 %0 %
1.8%
3.9% (incl. ? %)
?
Low estimate
High estimate
Measured: data centers, networks, devices
Unmeasured zone: heavy, poorly optimized web apps
A hole in the data that no one fills

ITU and IEA confirm digital’s fast rise. But the part driven by code and bloated web apps stays unquantified worldwide.

72%
reduction in emissions per visit after Jisc optimized one high-traffic page (1.09 g → 0.30 g CO₂)
// estimate bottom-up, not top-down

perf-sentinel’s bottom-up approach against the top-down of current tools

Top-down approach
Current IT and carbon tools
•A share of averages: data-center draw, sector ratios.
•Estimates a global footprint from the cloud bill or headcount.
•Gives a yearly number, but not the detail of what weighs.
Result
A global figure, not attributable and not actionable.
Bottom-up approach
perf-sentinel on heavy web apps
✓Observes the real application, query by query.
✓Translates each operation into energy then carbon (recognized method).
✓Pinpoints avoidable waste and its cost.
Result
A quantified hotspot, attributable to the code and directly actionable.
// what gets detected

Twelve I/O anti-patterns, at the protocol level

On the SQL and HTTP requests your services already emit, whatever the language or ORM.

01
N+1 SQL
The same query template fired ≥ N times within one trace.
02
N+1 HTTP
The same URL template called ≥ N times within one trace.
03
N+1 messaging
The same destination published to ≥ N times within one trace.
04
Redundant SQL
Identical query, identical parameters, same trace.
05
Redundant HTTP
Identical call, identical parameters, same trace.
06
Slow SQL
Query duration above the configured threshold.
07
Slow HTTP
Request duration above the configured threshold.
08
Slow messaging
Publish duration above the configured threshold.
09
Excessive fanout
A span starts ≥ N children in parallel.
10
Chatty service
A → B repeatedly within a single user request.
11
Pool saturation
Concurrent in-flight requests above the pool size.
12
Serialized calls
Sequential I/O that could be parallelized.

Every finding carries: type, severity, normalized template, occurrences, source endpoint, suggestion, source location and GreenOps impact. In daemon mode, cross-trace correlation is added.

// four ways to run it

1 binary, 2 modes, 4 postures

mode batch · local
Exploration

Locally: keyboard drill-down across Analyze · Inspect · Explain in a TUI, or a single-file offline HTML dashboard to open and share. Built-in demo, nothing to set up.

mode batch · CI
CI batch

On captured traces: exit 1 past a threshold, SARIF output for code scanning, deterministic JSON. A gate that never flickers.

mode daemon · sidecar
Sidecar

One daemon per service for isolated debugging, ingesting its OTLP traces right beside it.

mode daemon · central
Centralized

A single long-running daemon an OTel Collector routes to: gRPC :4317 + HTTP :4318, Prometheus /metrics, live dashboard, query API and cross-trace correlation.

Deployment in depth in the guide →
// built in rust

A single Rust binary, measured

RustVersion 1.97.1

Edition 2024, statically linked against musl and shipped in FROM scratch images. The figures below time the analysis pipeline alone (single-threaded, on synthetic datasets), so they isolate pipeline cost, not end-to-end throughput.

576k–1.2M
events/s, pipeline throughput (GCP c3-standard-8 x86 to M4 Pro)
0.8–1.9 µs
per event, p50 to p99
~17 MB
daemon RSS at rest (≈190 MB under ~1M evts/s)
Rust 2024
with a static musl binary and a FROM scratch image
Full benchmarks in the docs →
// greenops

Every avoidable I/O has a cost,
in time, energy and carbon

co2.total = (E × I) + M

Cutting N+1s and redundant calls improves response times and energy use alike: the two goals don't compete. co2.total follows the Software Carbon Intensity v1.0 numerator (ISO/IEC 21031:2024): energy used (E) times the electricity grid carbon intensity (I), plus embodied hardware emissions (M), summed over the analyzed traces.

I/O intensity score (IIS)
An endpoint's total I/O operations divided by its number of invocations.
I/O waste ratio
Avoidable operations over total operations, the directly recoverable share.
Multi-region co2.total
SCI v1.0 numerator, automatic per-region scoring when spans carry cloud.region.

Directional estimate (~2× bracket in proxy mode, tighter with a measured source: Alumet RAPL, Scaphandre RAPL, Kepler eBPF, Redfish BMC or cloud SPECpower + calibration, live grid intensity via Electricity Maps). Usable as activity data for Watershed · Sweep · Greenly · Persefoni, or to demonstrate RGESN compliance. It can also emit periodic public energy and carbon disclosure reports (quarterly or yearly JSON, optional Sigstore signature, hash-verifiable).

GreenOps metrics in the guide →Energy & carbon, in plain language →
// how it compares

Lightweight, agnostic, CI-native, carbon-aware

Capability
Typical commercial APM
perf-sentinel
Runtime footprint
Agent ~100–150 MB RSS
Standalone binary <20 MB RSS
Language coverage
Per-language agents or SDK
Any OTel-instrumented runtime
N+1 SQL & HTTP detection
Yes, agent-bound
Yes, protocol-level
Cross-service correlation
Yes
Yes, via trace ID
Native CI quality gate
Alerts, no gate
Yes, exit 1 on threshold
Per-span carbon attribution
No
Yes (SCI-aligned, directional)
GreenOps score (IIS, waste ratio)
No
Built-in
License & hosting
Proprietary SaaS, usage-based
AGPL-3.0, fully self-hostable

'Typical commercial APM' generalizes agent-based SaaS tools such as Datadog and New Relic; exact behavior varies by product, and footprints are order-of-magnitude estimates from public deployments. perf-sentinel is not a full APM and does not replace an observability suite, it sits alongside one. The full per-tool comparison (incl. Sentry, Hypersistence, Digma, Pyroscope, OTJAE) lives in the docs.

Full comparison in the guide →

What perf-sentinel is not

✗Not a full APM replacement. No RUM, no log aggregation, no distributed profiling. It does render dashboards of its own (a self-contained HTML report, a trace-browsing TUI and a live operator TUI, plus a Grafana dashboard over /metrics), but it has no alerting UI: alerting is delegated to Prometheus and Alertmanager, with operational rules shipped in the Helm chart. If you need the rest, Datadog, New Relic and Sentry remain the right tools.
✗Not a continuous profiler. It observes I/O patterns at the protocol level; it does not sample on-CPU time, allocations or stack traces. For flame graphs and language-aware CPU/memory profiling, Grafana Pyroscope is the open-source counterpart and pairs well: pyroscope tells you where compute time goes, perf-sentinel tells you which I/O patterns drive that time.
✗Not a monitoring platform. Daemon mode does analyze live and serves findings, metrics and correlations over HTTP, but it retains a bounded ring of recent findings (10,000 by default) rather than a queryable history, and it neither builds custom dashboards nor routes alerts. The center of gravity stays CI quality gates and post-hoc trace analysis.
✗Not (yet) a standalone regulatory carbon accounting platform. Standalone CSRD or GHG Protocol Scope 2/3 reporting requires third-party verification and non-IT scopes it does not cover. Exact scope, pairings (Watershed, Sweep, Greenly, Persefoni) and the RGESN case: see the GreenOps section.
✗Not a replacement for measured energy. The I/O-to-energy model is a directional estimate, not a measurement. For more accurate measured power, plug in Alumet (x86 RAPL, top of the precedence chain), Scaphandre (x86 RAPL), Kepler (eBPF, ARM-friendly) or Redfish (bare-metal BMC wall-plug), all four supported as inputs, or use cloud provider energy APIs. For what software-only attribution can and cannot cover on a typical server, see the limitations docs.
✗Not zero-config. Protocol-level detection requires OTel instrumentation in your apps. If your stack does not emit traces, perf-sentinel has nothing to analyze.
✗Not an IDE plugin. For in-IDE feedback on JVM/.NET code as you type, Digma offers a well-integrated JetBrains experience.
// license

AGPL-3.0, and what it means for your code

open source

A practical, legal-team-friendly summary so nobody has to dig through the repository. perf-sentinel is licensed under the GNU Affero General Public License v3.0.

✓
Your services stay yours

Running perf-sentinel does not place your own services under AGPL. It is a standalone process: your applications only send it OpenTelemetry traces over the network (OTLP), a remote communication and not a compile-time link, so it creates no derivative work and imposes no licensing obligation on your code.

✓
Unmodified binaries, no obligation

The AGPL covers perf-sentinel’s own source code. Using the official binaries or container image unmodified triggers no copyleft obligation of any kind.

The one condition: if you modify perf-sentinel and offer the modified version to third parties over a network, article 13 requires you to make that modified source available to those users. This is a practical summary, not legal advice. Consult your legal team if in doubt.

Put the sentinel in your pipeline

Built-in demo with nothing to install on the app side, then a quality gate on captured traces or an OTLP daemon beside your tracing.

$ perf-sentinel demo # terminal report
$ perf-sentinel demo --tui # interactive TUI
$ perf-sentinel demo --html demo.html # HTML dashboard
{{ personaPrompt }}
{{ personaHint }}
perf sentinelperf sentinel
GitHub
{{ eyebrowHero }}{{ eyebrowHeroGreen }}

{{ heroTitle }}

{{ heroSub }}

{{ embedCaption }}
{{ prereqTitle }}

{{ prereq1Label }} {{ prereq1Text }} {{ prereq1Setup }} {{ prereq1Link }}. {{ prereq1Dd }} {{ prereq1DdLink }}.

{{ prereq2Label }} {{ prereq2Text }} {{ prereq2Link }}.

{{ prereq3Label }} {{ prereq3Text }} {{ prereq3Link }}.

{{ prereq4Label }} {{ prereq4Text }} {{ prereq4Link }}.

{{ whyEyebrow }}

{{ whyT1 }}{{ whyTName }}{{ whyT2 }}

{{ whyP1 }}

{{ whyP2 }}

{{ whyP3 }}

{{ whyP4 }}

{{ carbonEyebrow }}

{{ carbonT1 }}{{ carbonTW }}{{ carbonT2a }}
{{ carbonT2b }}{{ carbonTW2 }}{{ carbonT3 }}

{{ carbonIntro }}

{{ carbonChartTitle }}
5 %4 %3 %2 %1 %0 %
{{ carbonAnnBasse }}
{{ carbonAnnHaute }} {{ carbonAnnHauteSubPre }}{{ carbonAnnHauteQ }})
?
{{ carbonBarBasse }}
{{ carbonBarHaute }}
{{ carbonLegMeasured }}
{{ carbonLegUnmeasured }}
{{ carbonChartSrc }}ITU 2025, IEA 2025, Freitag et al. 2021
{{ carbonNarrTitle }}

{{ carbonNarrText }}

{{ carbonStatNum }}
{{ carbonStatText }}
{{ carbonCmpTitle }}

{{ carbonCmpSub }}

{{ carbonTdEyebrow }}
{{ carbonTdTitle }}
•{{ pt.t }}
{{ carbonResultLabel }}
{{ carbonTdResultA }}{{ carbonTdResultB }}{{ carbonTdResultC }}{{ carbonTdResultD }}.
{{ carbonBuEyebrow }}
{{ carbonBuTitle }}
✓{{ pt.t }}
{{ carbonResultLabel }}
{{ carbonBuResultA }}{{ carbonBuResultB }}{{ carbonBuResultC }}{{ carbonBuResultD }}.
{{ detEyebrow }}

{{ detT1 }}{{ detWAnti }}{{ detT2 }}

{{ detIntro }}

{{ p.n }}
{{ p.name }}
{{ p.trigger }}

{{ detFoot }}

{{ modEyebrow }}

{{ modTitle }}

{{ m.tag }}
{{ m.title }}

{{ m.desc }}
{{ modesMore }} →
{{ perfEyebrow }}

{{ perfT1 }}{{ perfWRust }}{{ perfT2 }}

Rust{{ perfBadge }}

{{ perfIntro }}

{{ s.value }}
{{ s.label }}
{{ perfMore }} →
{{ goEyebrow }}

{{ goT1 }}{{ goWCost }},
{{ goT2 }}{{ goWEnergy }}{{ goT3 }}{{ goWCarbon }}

co2.total = (E × I) + M

{{ goBodyA }}co2.total{{ goBodyB1 }}Software Carbon Intensity v1.0{{ goBodyB2 }}ISO/IEC 21031:2024{{ goBodyB3 }}

{{ g.title }}
{{ g.body }}

{{ goNote }}

{{ goMore }} →{{ goEnergy }} →
{{ cmpEyebrow }}

{{ cmpT1 }}{{ cmpWCarbon }}

{{ cmpHCap }}
{{ cmpHApm }}
perf-sentinel
{{ c.cap }}
{{ c.apm }}
{{ c.ps }}

{{ cmpFoot }}

{{ cmpMore }} → {{ supplyMore }} →

{{ cpNotTitle }}

✗{{ n.lead }} {{ n.body }} {{ n.refText }}.
{{ licEyebrow }}

{{ licTitleA }}{{ licTitleB }}

open source

{{ licIntro }}

✓
{{ licC1Title }}

{{ licC1Body }}

✓
{{ licC2Title }}

{{ licC2Body }}

{{ licDisclaimer }}

{{ ctaTitle }}

{{ ctaText }}

$ perf-sentinel demo # {{ demoCmt1 }}
$ perf-sentinel demo --tui # {{ demoCmt2 }}
$ perf-sentinel demo --html demo.html # {{ demoCmt3 }}