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

Metrics	Logs	Traces
	✓

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.

- 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.

- 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

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
• IsMatch — OTTL function reference

Bindplane Resources

These filtering processors operate on logs and can be combined to refine which records reach a destination:

• Filter by Condition
• Filter by Regex
• Filter Severity
• Parse Severity