> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/processors/filter-severity.md).

# Filter Severity

Drops log records whose severity is lower than a configured minimum, keeping records at or above that threshold. An optional OTTL condition scopes which records the threshold is applied to; records that do not match the condition pass through untouched. Operates on logs only.

### Supported Telemetry

| Metrics | Logs | Traces |
| ------- | ---- | ------ |
|         | ✓    |        |

### Configuration

<figure><img src="/files/JDEQB4jL2Tf23PPBRqR9" alt="Bindplane docs - Filter by Severity - image 1"><figcaption></figcaption></figure>

**Logs**

| Parameter | Type                                         | Required | Default   | Description                                                                                                                                                                                              |
| --------- | -------------------------------------------- | -------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Severity  | Enum: TRACE, DEBUG, INFO, WARN, ERROR, FATAL | Yes      | TRACE     | The minimum severity to keep. Log records with a lower severity are dropped. With the default `TRACE`, nothing is dropped on severity alone.                                                             |
| Condition | OTTL Condition                               | No       | *(empty)* | An OTTL condition that must evaluate to true for the severity threshold to apply to a record. Leave empty to apply the threshold to all logs. Records that do not match are kept regardless of severity. |

The severity order, from lowest to highest, is `TRACE` < `DEBUG` < `INFO` < `WARN` < `ERROR` < `FATAL`. Setting Severity to `WARN`, for example, drops `TRACE`, `DEBUG`, and `INFO` records while keeping `WARN`, `ERROR`, and `FATAL`.

### Examples

#### Keep only WARN and above

Drop everything below `WARN` across all logs. Leave Condition empty so the threshold applies to every record.

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: filter-severity
spec:
  type: filter_severity
  parameters:
    - name: severity
      value: WARN
    - name: condition
      value: ""
```

#### Apply the threshold only to a subset of logs

Drop records below `ERROR`, but only for logs from the `auth` service. Records from any other service are kept regardless of severity because they do not match the condition.

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: filter-severity
spec:
  type: filter_severity
  parameters:
    - name: severity
      value: ERROR
    - name: condition
      value: resource.attributes["service.name"] == "auth"
```

### Configuration Tips

* The default Severity of `TRACE` is a no-op for the threshold, since every level is at or above `TRACE`. Set a higher level for the processor to drop anything.
* Records with no severity set are treated as the lowest severity, so a non-`TRACE` threshold drops them. Set a Condition that excludes unset-severity records if you need to keep them.
* Use the Condition to limit the threshold to noisy sources rather than chaining multiple severity filters. One instance with a scoped condition is cheaper than several.

### Troubleshooting

#### No logs are being dropped

Symptoms: log volume is unchanged after adding the processor.

Solutions:

1. Confirm Severity is set above `TRACE`. The default keeps every record.
2. If a Condition is set, verify it evaluates to true for the records you expect to filter. Records that do not match the condition are never dropped.

#### Too many logs are being dropped

Symptoms: records you wanted to keep are missing downstream.

Solutions:

1. Lower the Severity threshold, or scope it with a Condition so it applies only to the intended sources.
2. Check whether the dropped records have an unset severity. Unset severity is treated as the lowest level and is dropped by any non-`TRACE` threshold.

#### Severity mapping looks wrong

Symptoms: records are filtered at a different level than expected.

Solutions:

1. Verify the upstream parsing stage maps the source's severity into the OpenTelemetry severity number correctly. The threshold compares against the normalized OTel severity, not the raw text in the log body.

### Standalone Processor

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: filter-severity
spec:
  type: filter_severity
  parameters:
    - name: severity
      value: WARN
    - name: condition
      value: resource.attributes["service.name"] == "auth"
```

### Related Resources

* [Filter Processor — OpenTelemetry Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/filterprocessor/README.md)
* [Filter by Field](/integrations/processors/filter-by-field.md)
* [Filter by Condition](/integrations/processors/filter-by-condition.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bindplane.com/integrations/processors/filter-severity.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.