Splunk Cloud license usage differs between Cribl Splunk LB S2S and Cribl HEC destinations — date_*/timepos fields to blame?

Hi @johankellermansciberio — great question, and you're on the right track. This is a known behavior difference between Splunk's S2S (native Splunk protocol) and HEC ingestion paths.

What's happening

When Splunk ingests data via S2S (Splunk LB), the indexer automatically parses the event's timestamp and adds metadata fields like date_month, date_mday, date_year, date_hour, date_minute, date_second, timepos (and timestartpos, timeendpos) during indexing. These fields are generated by Splunk's datetime.xml indexer-time parsing and contribute to the indexed event size.

When data comes in via HEC, Splunk does not automatically generate these date_* fields the same way — the event is indexed differently, and these metadata fields are either absent or handled at search time instead of index time.

This means the same raw event ends up with a different number of indexed fields depending on the protocol, which translates to different Splunk license consumption (Splunk Cloud bills on indexed volume).

When you strip date_*/timepos fields in a Cribl Stream pipeline before sending to Splunk Cloud:

• License usage drops because the events are smaller (fewer indexed fields)
• But the fields go missing because Splunk was relying on them being present from the S2S path

Suggested approaches

1. Send via Splunk HEC destination and let Splunk compute date_* at search time — When using HEC, Splunk can still compute date_* fields at search time using eval if needed. This avoids the index-time bloat while keeping the fields available for searches. You may need to adjust your SPL that depends on these fields.

2. Use Cribl to add the fields explicitly via an Eval function — Instead of letting Splunk generate date_* fields at index time (which adds to license volume), you can use a Cribl Eval function to compute them from _time and include them in the event payload. This gives you control over exactly which fields are added:

   date_year: _time.getFullYear()
   date_month: ("0" + (_time.getMonth()+1)).slice(-2)
   date_mday: ("0" + _time.getDate()).slice(-2)
   date_hour: ("0" + _time.getHours()).slice(-2)
   date_minute: ("0" + _time.getMinutes()).slice(-2)
   date_second: ("0" + _time.getSeconds()).slice(-2)
   

   Then send via HEC. You get the fields without the Splunk indexer adding its own.

3. Use the Splunk LB (S2S) destination and accept the overhead — If downstream searches hard-depend on date_* fields being index-time fields, the simplest path is to send via Splunk LB (S2S) and accept the license cost difference. You can use Cribl's data reduction capabilities elsewhere (filtering, cloning, dropping unnecessary events) to offset the volume increase.

4. Consider DATETIME.XML configuration on the Splunk side — Work with your Splunk admin to see if date_*field generation can be adjusted in the Splunk props.conf for the relevant sourcetype, or if the fields can be made search-time computed instead of index-time.

Recommendation

The cleanest long-term approach is usually option 1 or 2 — send via HEC and compute date_* fields at search time (via Splunk) or at pipeline time (via Cribl). This avoids the index-time field bloat while keeping the fields available for your users.

Relevant docs:

• Splunk LB Destination
• Splunk HEC Destination
• Eval Function

Hope this helps! 🚀

Thanks ​@Dan Schmitz 
Great info , but in our case it is actually HEC that is consuming more licens compared to S2S (sending from Cribl)
The data path is | source → Splunk HF → Cribl → Splunk Cloud via HEC or S2S |
Do you have an idea of what can cause that and how to mitigate?

Thanks

/Johan