Cribl Stream 101: Sources, Routes, Pipelines, and Destinations

One sentence, then the pieces

Cribl's Basic Concepts page starts with a mental model worth keeping whole: Cribl Stream is "a system that receives events from various sources, processes them, and then sends them to one or more destinations". For people new to the product, that single sentence is the entire job description, and everything else in Stream is a named piece of it.

The same page names the basic interface concepts: Sources, which collect data, and Routes, which manage data flowing through Pipelines, which consist of Functions. Add Destinations at the end of the line and you have the four objects this primer covers. The rest of the post takes each object in turn, in the docs' own wording.

Sources

The Basic Concepts page defines a Source plainly: Sources are "configurations that enable Cribl Stream to receive data from remote senders (such as Splunk, TCP, Syslog) or to collect data from remote file stores or the local machine". A Source is an input configuration. You pick a type, aim it at a remote sender, file store, or the local machine, and events start arriving from it.

For the full picture of what can feed Stream, the Integrations overview is the entry point. It covers both ends of the data path, since integrations "encompass both Sources and Destinations". On the entry side specifically, Sources are "the entry points in the event processing order, enabling the collection of raw data for subsequent processing".

Pipelines and functions

The Pipelines documentation states its case bluntly: "Pipelines are the heart of Cribl Stream processing". A Pipeline contains a logical sequence of Functions, and, as with Routes, "Cribl Stream evaluates the Functions in a Pipeline in top-down order". The Basic Concepts page defines the unit: a Function is "a piece of code that executes on an event", and it "encapsulates the smallest amount of processing that can happen to that event".

Functions do not all have to act on every event. The Basic Concepts page notes that Functions can optionally be configured with filters, "to limit their processing scope to matching events only". The Pipelines page names the Function categories you will meet most, and gives a rule of thumb for extractors: use the Regex Extract Function if you only need one or a few fields, and the Parser Function if you need all or most of an event's fields. The same page also names the Drop Function, the Lookup Function, and the Chain Function, which sends the output of one Pipeline to another Pipeline or Pack.

You will also notice a set of built-ins right away. The Pipelines page lists default Pipelines that Cribl Stream creates automatically in each Worker Group, including devnull, main, and passthru, and it recommends building your own custom Pipelines for production rather than attaching the defaults. If you would rather skip manual construction, the page points at Cribl Copilot: "you can describe what you want to do with your data and Copilot Editor will generate a working Pipeline".

Routes

Before events are transformed, Cribl Stream first selects which of them go where, and this selection is "normally made via Routes", per the Routes documentation. A Route applies a filter expression to incoming events and sends matching results to the appropriate Pipeline or Pack. "Filters are JavaScript-syntax-compatible expressions that are configured with each Route", and the page opens with two examples:

true
source=='foo.log' && fieldA=='bar'

The first filter matches everything. The second matches one named source and one field value at the same time. Both lines are copied from the example list on the Routes documentation page.

"Routes are evaluated in their display order, from the first Route in the list to the last". Each Route can be associated with only one Pipeline and one Destination, so a deployment's routing table behaves like a stack of checks evaluated from top to bottom. The docs end this section with plain advice: "We recommend always using a catch-all Route", so events that match nothing still have a defined destination.

Most of the subtlety in the Routes page is one setting, the Final toggle. It is on by default: when it is on, a Route's matched events are processed and do not continue to the Routes below it. Toggle Final off and the matched events arrive at the Route's Pipeline as clones, while all events, matched or not, continue down the list to the next Route. That is how one set of events can be processed in multiple ways and delivered to different destinations.

Destinations

At the far end sit Destinations. The Integrations overview defines them as "the exit points in the event processing order", "sending enriched and transformed events to the appropriate systems for storage, analysis, or further processing". The Basic Concepts page is concrete about where that can end up: "Cribl Stream can send data to many different Destinations, including Splunk, Kafka, Kinesis, InfluxDB, Snowflake, Databricks, TCP JSON, and others".

The Integrations page also names the three key concepts for keeping data flowing: Destination Backpressure Triggers, Persistent Queues, and Load Balancing. For a first deployment, Persistent Queues matter most: they "provide a temporary storage mechanism on disk" to guard against integrations that are slow or unavailable.

The order an event is processed

The Event Processing Order page documents how "all events in the Cribl Stream ecosystem are processed linearly, from left to right". The stages, in the page's own order:

1. Sources: "Data arrives from your choice of external providers", and many internal fields are added during the event parsing within the Source.
2. Custom command (optional, where available): the input's data can be passed to an external command before it continues downstream.
3. Event Breakers (optional): these "can, optionally, break up incoming bytestreams into discrete events".
4. Time filters: in Collector jobs, they discard events outside the specified time range.
5. Fields/Metadata (optional): enrichments you add to each incoming event before it proceeds further.
6. Persistent queue, Source side (optional): per-Source disk buffering to maximize data delivery despite downstream backpressure.
7. The internal field __inputId is added, after the event exits the Source.
8. Pre-processing Pipeline (optional): a single Pipeline attached to the input that conditions and normalizes the data before it proceeds further.
9. Routes map the events to Processing Pipelines and Destinations.
10. Processing Pipelines "perform most event transformations", as a linear series of Functions.
11. Post-processing Pipeline (optional): a Pipeline appended on the way into the Destination.
12. Persistent queue, Destination side (optional): disk buffering "during imbalances between inbound and outbound data rates".
13. Destinations: "Each Route/Pipeline combination forwards processed data to your choice of streaming or storage Destination".

Two notes from the same page round out the picture. The three Pipeline types (pre-processing, processing, post-processing) share the same basic internal structure, "they're a series of Functions", and they "differ only in their position in the system". And the troubleshooting direction is the opposite of the data flow: "Troubleshoot event processing in Cribl Stream from right to left. Start at the Destination, and check for block status from the Destination back to the Source".

QuickConnect

One final piece from the Basic Concepts page: "QuickConnect is a visual interface for setting up data flow through your Cribl Stream deployment". You drag connections between Sources and Destinations, optionally including or excluding Pipelines or Packs. The page's one major constraint: "QuickConnect completely bypasses" Routes, so QuickConnect configurations have no Routing table and no conditional cloning, and "every QuickConnect connection is parallel and independent". The Routes documentation calls it a "rapid visual configuration tool as an alternative to Routes". The Routing menu switches between the Data Routes and QuickConnect views.

Frequently asked questions

What are the four core objects in a Cribl Stream deployment?

Cribl Stream has four core objects, and the Basic Concepts page names them in one line. Sources collect data, Routes manage data flowing through Pipelines, Pipelines consist of Functions, and Destinations send the result onward.

How does a Cribl Stream Route decide which events go where?

A Route applies a JavaScript-syntax-compatible filter expression and sends matching events to its Pipeline or Destination. Routes are evaluated in display order, from the first in the list to the last.

What does the Final toggle do on a Cribl Stream Route?

The Final toggle is on by default: matched events are processed and stop there. Toggle it off and matched events arrive at the Pipeline as clones, while all events continue to the next Route.

In what order does Cribl Stream process an event?

Events are processed linearly from left to right: Sources, optional event breaking, Routes, Processing Pipelines, and finally Destinations. Troubleshooting runs in the opposite direction, from the Destination back to the Source.

Verified against Cribl Stream 4.20 documentation on September 30, 2026.