The HTTP sink sends observability events to an arbitrary HTTP endpoint. It’s the “generic egress” option when you want to push logs, metrics, and traces into:

It supports batching, buffering, configurable encoding + framing, and multiple auth methods (basic, bearer, custom header, AWS signing).

The full destination URI to send requests to.

Because it’s templateable, you can route per-event to different paths/hosts (careful: this can explode the number of distinct upstream targets, which affects connection reuse and performance).

Defines how worker authenticates requests.

Supported strategies:

Practical notes:

Controls how events are serialized into bytes and also determines which input types are supported for a chosen codec.

Common choices in practice:

You can also constrain output fields:

Defines how multiple encoded events are delimited inside the request body.

Key methods:

If your receiver expects NDJSON, the classic pairing is:

Controls when worker flushes a set of events into one HTTP request:

Batch tuning is the main lever for:

Controls local buffering for backpressure / durability:

This is the main control for “what happens when the endpoint slows down”.

Compresses the HTTP request body:

Use compression when bandwidth is expensive or payload volume is high. It trades CPU for network savings and can help if the receiver supports it efficiently.

HTTP method used for sending requests. Default is POST.

request.headers lets you attach arbitrary headers to every request.

Both header names and values can be templateable, so you can do patterns like:

Note: the older headers option is deprecated in favor of request.headers.

Standard proxy config with:

TLS settings for secure delivery:

payload_prefix and payload_suffix allow wrapping character-delimited JSON payloads into a larger JSON object.

This is used when the receiver expects a JSON envelope like:

worker can emit the delimiters + wrapper as long as the prefix/suffix form valid JSON together.