> 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-http-status.md).
# Filter HTTP Status
Keeps log records whose HTTP status code falls within a chosen range and drops the rest. The status code is read from a `status` key found in either the log record's attributes or its body. Records whose status code falls outside the range, or that carry no recognizable status code, are dropped. This processor operates on logs only.
### Supported Telemetry Types
| Platform | Metrics | Logs | Traces |
| ----------------------- | ------- | ---- | ------ |
| Linux | | ✓ | |
| Windows | | ✓ | |
| macOS | | ✓ | |
| AIX | | ✓ | |
| Kubernetes Node | | ✓ | |
| Kubernetes Cluster | | ✓ | |
| Kubernetes Gateway | | ✓ | |
| OpenShift Node | | ✓ | |
| OpenShift Cluster | | ✓ | |
| OpenShift Gateway | | ✓ | |
| Google SecOps Pipelines | | ✓ | |
### Configuration
**Logs**
| Parameter | Type | Required | Default | Description |
| ------------------- | ---------------------------------- | -------- | ------- | ---------------------------------------------------------------------------------------- |
| Minimum Status Code | Enum: 100, 200, 300, 400, 500, 600 | Yes | 100 | The lowest status code to allow through. Records with a lower status code are dropped. |
| Maximum Status Code | Enum: 199, 299, 399, 499, 599 | Yes | 599 | The highest status code to allow through. Records with a higher status code are dropped. |
The range is evaluated by status-code class (1xx, 2xx, 3xx, 4xx, 5xx). Only classes fully contained within `[Minimum, Maximum]` are kept. With the default `100`–`599`, every class is in range, so the processor keeps everything and acts as a no-op. Narrow the range to start dropping classes.
### Examples
#### Keep only client and server errors (4xx and 5xx)
Set Minimum to `400` and Maximum to `599`. Records whose `status` is in the 1xx, 2xx, or 3xx classes are dropped; 4xx and 5xx records pass through. The status code is matched in the record's attributes or body, for example an attribute `status: 404` or a body containing `"status": 503`.
```yaml
- type: filter_http_status
parameters:
- name: minimum
value: "400"
- name: maximum
value: "599"
```
#### Keep only successful responses (2xx)
Set Minimum to `200` and Maximum to `299` to retain only the 2xx success class and drop everything else.
```yaml
- type: filter_http_status
parameters:
- name: minimum
value: "200"
- name: maximum
value: "299"
```
### Configuration Tips
* The status code must appear under a `status` key in the log record's attributes or body. Records without a matching `status` key are dropped, so place this processor after any parsing step that extracts the status code into a `status` field.
* Only whole status-code classes are evaluated. Choose Minimum and Maximum at class boundaries (for example `400`/`499`) rather than expecting an exact numeric cutoff within a class.
* The default `100`–`599` keeps all classes and drops nothing. Use it as a starting point, then tighten the range to filter.
### Troubleshooting
#### All records are being dropped
Symptoms: no logs reach the destination after enabling the processor.
Solutions:
1. Confirm the records actually carry a `status` key in their attributes or body. Records with no recognizable status code are dropped.
2. If the status code is nested or under a different key, add a parsing processor upstream to surface it as `status` before this processor runs.
#### Records I expected to drop are still passing through
Symptoms: out-of-range status codes still reach the destination.
Solutions:
1. Check the Minimum and Maximum values. The default `100`–`599` keeps every class and drops nothing.
2. Remember that filtering is by class. A range of `200`–`499` keeps the entire 2xx, 3xx, and 4xx classes; it does not exclude a specific code within a kept class.
#### Records appear twice or counts look off
Symptoms: filtering seems inconsistent across a batch.
Solutions:
1. Ensure only one Filter by HTTP Status instance acts on the pipeline, or that stacked instances use compatible ranges. Two instances with non-overlapping ranges can drop everything.
### Standalone Processor
```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
name: filter-http-status
spec:
type: filter_http_status
parameters:
- name: minimum
value: "400"
- name: maximum
value: "599"
```
### Related Resources
* [Filter Processor — OpenTelemetry Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor)
* [IsMatch — OTTL function reference](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/ottlfuncs/README.md#ismatch)
### Bindplane Resources
These filtering processors operate on logs and can be combined to refine which records reach a destination:
* [Filter by Condition](/integrations/processors/filter-by-condition.md)
* [Filter by Regex](/integrations/processors/filter-by-regex.md)
* [Filter Severity](/integrations/processors/filter-severity.md)
* [Parse Severity](/integrations/processors/parse-severity.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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.bindplane.com/integrations/processors/filter-http-status.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
