The Humio Logs sink enables worker to deliver log event data into a Humio backend using an ingestion token. Worker sends events in batches, and Humio can apply a parser at ingest time based on the configured event type.

This sink is a good fit when you want to push logs from Worker into Humio repositories (including cloud-hosted or self-managed deployments) and control how they are parsed/indexed at the destination.

Before configuring this sink, you typically need:

The Humio ingestion token used for authentication. This is the primary credential used by Worker to send events into Humio.

The base URL of the Humio instance (must include the scheme, e.g., https://). No path should be included, since worker uses the fixed ingestion paths.

If omitted, worker targets Humio cloud by default (as shown in the docs snippet).

The repository name to ingest into.

Use index when you want explicit repository selection (and your Humio deployment allows it).

Sets the event type for the events sent to Humio. Humio uses this as the parser name to apply at ingest time.

If you don’t set it, Humio defaults it to none (Humio’s default behavior).

Because it is templateable, you can drive parser selection dynamically per event (for example based on source/service).

The source associated with events sent to Humio, typically representing the original filename or origin identifier.

This maps to Humio’s @source.

Since it is templateable, you can encode useful origin metadata (pod name, container name, file path, etc.) consistently into Humio.

A list of event fields that are promoted into Humio’s “extra fields”.

This is the key control for deciding which log attributes become searchable/indexed as structured fields in Humio.

It also supports tagging behavior by specifying fields starting with # (Humio convention), allowing you to attach tags derived from the event content.

Overrides the log field used to retrieve the hostname to send to Humio.

Use this when your log events use a non-standard host field name.

Humio supports explicit timestamps in events:

Use these when:

Controls how worker serializes each event into bytes before sending.

Because Humio ingestion is sensitive to structure and parsing, encoding is where you decide:

Key controls include:

Controls compression applied to outbound payloads. Options include:

Use compression when bandwidth is constrained or when pushing high-volume logs over WAN links. If CPU is more constrained than bandwidth, disabling compression may improve throughput.

Configures how events are buffered before being sent to Humio.

This lets you choose between:

You also control what happens when buffers are full (e.g., block vs drop-newest), which affects loss vs backpressure behavior.

Controls how events are grouped into batches before send.

Typical batch tuning knobs:

Batch sizing is one of the most important levers for throughput and cost:

Allows routing Humio traffic through HTTP/HTTPS proxies, including:

This is useful in enterprise environments where outbound traffic must traverse controlled egress paths.

TLS settings control secure transport to Humio, including:

Use TLS for production deployments, especially when Humio is remote or cloud-hosted.

The Humio Logs sink sends worker log events to Humio using an ingest token, with flexible controls for destination selection (index), ingest parsing (event_type), structured search fields (indexed_fields), and timestamp mapping (timestamp_key). You can tune performance via batching, buffering, and compression, and align with enterprise constraints via proxy and TLS settings.