Migrate Splunk S2S to HEC with Cribl Stream

Why teams move from S2S to HEC

The reasons for the switch are stated plainly on Cribl's Splunk Cloud Platform and BYOL Integrations page: the HTTP Event Collector (HEC) is the preferred method for integrating with the Splunk Cloud Platform. It is easy to set up, offers superior compression, and efficiently load balances data across multiple indexers in a distributed Splunk environment. S2S can still be used "for specific scenarios, such as legacy integrations or granular data distribution", but for everything else, HEC generally provides a more straightforward and efficient integration process, in the page's words.

Two more facts frame the change: the Splunk HEC Destination reference page lists TLS support for the destination, and Cribl's step-by-step switching guide from S2S to Splunk HEC covers the full scope: prerequisites, the Splunk-side token and queue configuration, the new HEC Destination, and re-pointing every reference to the old S2S Destination.

The topology

The guide's prerequisites are a Cribl Stream instance and a Splunk instance, and it assumes Stream is already in the middle: QuickConnects Sources feed data into it, and routes deliver to a Splunk Single Instance or Splunk Load Balanced Destination, both speaking S2S to the indexers. The migration keeps Stream in the middle and changes only the last hop. The end-state topology, in the guide's own terms:

• QuickConnects Sources: unchanged. They keep feeding Stream and only get pointed at the new Destination instead of the old one.
• Cribl Stream: unchanged in the middle. The S2S Destination at the end of the data path is replaced by a Splunk HEC Destination.
• Splunk HEC Destination: new. Writes to the HEC endpoint, in the guide's example format for Splunk Cloud: https://http-inputs-<CLOUD_ORG>.splunkcloud.com/services/collector/event.
• Splunk S2S Destination: retired. The Single Instance or Load Balanced Destination the Sources and routes were pointing at.

The switch happens in two places. Under Data then Destinations, open the S2S Destination, and from its QuickConnects column click each Source and switch it to the HEC Destination. Then, on Processing and Packs and Routing and Data Routes, find every route that still names the S2S Destination, on the Data Routes page or on a Pack's Routes page, and change it to the HEC Destination, and Commit & Deploy. In a Distributed deployment the commit pushes the configuration to the Workers; on a standalone instance, changes take place as soon as they are saved.

The source side

"Source side" in this migration means the side where the HEC data lands (the Splunk instance), not a new Cribl Stream Source. The inbound-side work is one Splunk-side setting, the queue setting on the HEC input, plus the HEC token itself.

Why queue matters: if your Splunk Technology Add-ons include many index-time operations like SEDCMD or TRANSFORMS, be aware of potential data quality impacts. By default, Splunk HEC sends data through a queue where those operations (often referred to as extractions) may be applied, potentially altering the original data. The fix is to configure queue to use the rulesetQueue at per-token stanza level in inputs.conf, applying newer Ingest Actions through the Ruleset queue. The stanza, copied verbatim from the guide:

[http://cribl]
disabled = 0
index = main
token = ${SPLUNK_HEC_TOKEN}
queue = rulesetQueue

Add or modify it in the inputs.conf file, typically in the $SPLUNK_HOME/etc/system/local directory, replace ${SPLUNK_HEC_TOKEN} with your actual HEC token, save, and restart the Splunk instance for the changes to take effect.

The token is created in the Splunk UI: Settings then Add Data, select Monitor, then HTTP Event Collector. Name the token (the guide's example is cribl-HEC), select Automatic for Source type unless the token is dedicated to a specific Sourcetype, select your desired Allowed Indexes, and Submit. The result is a new, valid HEC token that Cribl Stream can use against the indexes you allow it to reach.

The destination side

In Cribl Stream, select Data then Destinations, then the Splunk tile and HEC, and Add Destination. The guide's field list for the modal: Output ID (a descriptive name), Load balancing (decide whether to enable it for this Destination), Splunk HEC Endpoints, Authentication method set to Manual, and HEC Auth token (the token created in Splunk). Depending on data volume and event size, the guide also suggests tuning Body size limit, Request concurrency, and Flush period (sec) in Advanced Settings, then Save, and Commit & Deploy in a Distributed deployment.

The Destination reference page fills in what those fields do. The Load balancing toggle exposes a table of Splunk HEC endpoints so you can specify multiple endpoints with load weights; if it is off and Stream is not sending data to all possible IP addresses, the page points to Round-robin DNS under Advanced Settings. Each row takes a HEC Endpoint URL and a Load Weight (a value greater than 0, with weights in the same order of magnitude for the best distribution). Supported paths: /services/collector/event (default), /services/collector/raw, and /services/collector/s2s; https is recommended for Splunk Cloud endpoints. Authentication is Manual (a plain HEC Auth token field) or Secret (a stored secret referencing the token, with a Create link for a new, reusable one). Optional settings cover Exclude current host IPs (visible only when load balancing is on), Backpressure behavior: block, drop, or queue events when all receivers are exerting backpressure, defaulting to Block, and Tags.

The data-path difference from S2S is one line in the reference: the data arrives to Splunk cooked and parsed, so it enters the data pipeline's indexing segment. Before trusting it at volume, use the Destination's Test tab: add the index field to Test input, click Run test, and a green Success banner confirms the endpoint and token are valid.

Splunk Cloud specifics

The Integrations page maps each deployment scenario to its supported Cribl Stream Destination and protocol:

• Splunk HEC Destination (Splunk HEC): Distributed Splunk Cloud Platform, and Bring Your Own License (BYOL) deployments (either in a non-Splunk cloud or on-prem).
• Splunk Load Balanced Destination (S2S): Distributed Splunk Cloud Platform, and BYOL deployments.
• Splunk Single Instance Destination (S2S): Single-instance Splunk Cloud Platform (trial or smaller deployments).

Two readings matter for this migration. If your target is a distributed Splunk Cloud deployment, the HEC Destination is the documented pairing and the S2S Destinations are the path being retired. The switch above is the documented direction of travel. For BYOL, the page advises leveraging the .pem and outputs.conf files already in use on your existing Splunk Universal Forwarders to keep the security setup consistent, with Splunk's documentation covering the details of securing indexers.

Migration gotchas the docs mention

The migration-relevant warnings and caveats the docs call out:

• A global queue change hits every HEC token. Modifying it in the global stanza of inputs.conf impacts all HEC tokens and may have unintended consequences for other HEC-based integrations, which is why the guide scopes it to the Cribl token's stanza.
• Splunk Cloud requires a ticket. On Splunk Cloud you must open a ticket with Splunk to request a change to the inputs.conf file, and request that the queue setting change only for the Cribl integration, not on a global level.
• Allowed Indexes and _internal. If you want to send Splunk logs such as data from _internal, set the Allowed Indexes to N/A; the guide also notes you may want different tokens for different types of data.
• Do not toggle Enable Indexer Acknowledgement. With it on, Splunk receivers expect the Channel GUID to be passed in, and requests fail with a status code of 400 and the response text "Data channel is missing", per the Destination page's example error.
• Splunk Cloud body size limit. For Splunk Cloud targets, Cribl recommends a maximum value of 1 MB for Body size limit (KB) under Advanced settings, the upper limit defined by the maximum content length of the default HEC provided by Splunk Cloud.
• 429 responses are dropped by default. A 429 (Too Many Requests) response not listed in the retry settings is treated as a non-retryable 4xx error and dropped; include the code under Retries to have it retried. 5xx responses are retryable but do not trigger Persistent Queue usage, and plain 4xx responses are dropped by default.
• Load balancing changes settle over a few seconds. Enabling load balancing for the first time, or editing a load weight after data is already load-balanced, might take a few seconds to register.
• Change incrementally and validate as you go. Cribl's own recommendation: make these changes incrementally and validate each change inside your Splunk instance for any data irregularities before you move on.

Frequently asked questions

Why do teams move from Splunk S2S forwards to HEC with Cribl Stream?

The Cribl docs state that HEC is the preferred method for integrating with the Splunk Cloud Platform. It is easy to set up, offers superior compression, and load balances data across multiple indexers.

What changes in the topology when Cribl Stream migrates an S2S path to HEC?

Only the last hop changes. The S2S Destination at the end of the data path is replaced by a Splunk HEC Destination, and the Sources and routes are re-pointed at it while Cribl Stream stays in the middle.

Why does a Cribl Stream HEC migration set queue to rulesetQueue only in the Cribl token stanza?

HEC data passes through a queue where index-time operations like SEDCMD and TRANSFORMS may be applied, potentially altering the original data. A global change impacts every HEC token, so the guide scopes it to the Cribl token's stanza.

What Body size limit does the Cribl Stream documentation recommend for Splunk Cloud targets?

The documentation recommends a maximum of 1 MB for the Body size limit in Advanced settings. That is the upper limit of the maximum content length of the default HEC that Splunk Cloud provides.

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