> ## Documentation Index
> Fetch the complete documentation index at: https://docs.odigos.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Noisy Operation

> Drop or down-sample low-value traffic — health probes, scrapes, heartbeats — early at the root span with head sampling.

**Noisy Operation** rules drop or down-sample traffic that you treat as having little or no value—for example Kubernetes liveness and readiness probes, periodic health checks, or scraper traffic. They are the **first** stage in the [rule evaluation pipeline](./overview#order-of-operations-between-categories): a trace that matches a Noisy rule is **not** evaluated against Highly Relevant or Cost Reduction rules.

## How they're evaluated

* **Head sampling at the root span.** The keep/drop decision is made on the entry span, before child spans are processed.
* **No trace buffering.** Because the decision happens at the start of the trace, the gateway does not need to wait for an [aggregation window](../head-and-tail-sampling#aggregation-window).
* **Lowest overhead.** Head sampling is the **most efficient** sampling type, with the **least CPU and memory** impact on collectors and gateway.

<Warning>
  Head-sampled Noisy rules require an instrumentation agent that supports head sampling. Today this includes **Node.js**, **Python**, **Java**, and **Go**. For other languages or runtimes, Noisy rules are **evaluated at tail-sampling time** instead—the trace is buffered for the full [aggregation window](../head-and-tail-sampling#aggregation-window) before the drop happens, so the efficiency advantages above (no buffering, lowest overhead) **do not apply**.
</Warning>

## Possible outcomes

A matching trace is either:

* **Dropped** — never exported and never evaluated against Highly Relevant or Cost Reduction rules.
* **Sampled down** — kept at a configured percentage. The kept fraction also skips later categories.

<Note>
  Dropped traces do not continue to other categories. If you need a noisy route to remain visible when something goes wrong (for example a failing health check), replace the Noisy rule with a **Highly Relevant** rule on errors and use a **Cost Reduction** rule to cap the successful traffic.
</Note>

## Built-in rule: Kubernetes Health Probes

Odigos ships a single built-in Noisy rule, **Kubernetes Health Probes**, which drops traces for the **liveness**, **readiness**, and **startup** probe paths discovered on each workload's Kubernetes manifest.

The rule's **Keep Percentage** controls how much probe traffic is retained. Common configurations:

* **0% — drop everything (default).** Probes carry no signal about application behavior, so dropping them keeps the pipeline focused on real traffic and minimizes cost.
* **\~2% — sparse liveness signal.** For services with little or no real traffic, a small permanent value keeps a handful of probe traces flowing. The retained samples act as a "service is up" indicator on dashboards that would otherwise look empty, helping distinguish a *quiet* service from a *silently broken* one.
* **100% — debug probe failures.** Temporarily raise while investigating failing or flaky probes, then reset to your normal value once resolved.

<Tip>
  Only **HTTPGet** probes declared on the manifest are matched. Probes defined as `exec` or `tcpSocket`, or probes routed through different paths (custom configuration, ingress rewrites, service-mesh wrappers), are not auto-handled; add an explicit Noisy rule for those paths if needed.
</Tip>

## Typical use cases

* Kubernetes `liveness`, `readiness`, and `startup` probes
* Internal `/health` and `/healthz` endpoints
* Prometheus `/metrics` scrape traffic
* Background heartbeats and keep-alive pings
* High-volume, low-value endpoints — for example a static asset route, a polling endpoint, or an autocomplete API that produces many traces without contributing to debugging or SLOs