Splunk HEC: Send Events via HTTP Event Collector (2026)

Splunk’s HTTP Event Collector (HEC) can, surprisingly, be slower than traditional file-based logging for very high-volume, synchronous ingestion.

Let’s see HEC in action. Imagine you have a Python script that’s generating logs and you want to send them directly to Splunk.

import requests
import json
import time

# Replace with your Splunk HEC URL and token
splunk_url = "https://your_splunk_host:8088/services/collector"
splunk_token = "YOUR_HEC_TOKEN"

headers = {
    "Authorization": f"Splunk {splunk_token}",
    "Content-Type": "application/json"
}

def send_to_splunk(event_data):
    payload = {
        "event": event_data,
        "sourcetype": "my_custom_sourcetype",
        "index": "main"
    }
    try:
        response = requests.post(splunk_url, headers=headers, data=json.dumps(payload), verify=False) # verify=False for self-signed certs, use True in prod
        response.raise_for_status() # Raise an exception for bad status codes
        print(f"Successfully sent event: {event_data}")
        return True
    except requests.exceptions.RequestException as e:
        print(f"Error sending event: {event_data} - {e}")
        return False

if __name__ == "__main__":
    for i in range(10):
        log_message = f"This is log message number {i} at {time.time()}"
        send_to_splunk(log_message)
        time.sleep(0.1) # Small delay to simulate event generation

This script sends individual log messages as JSON payloads to the HEC endpoint. Splunk then processes these events, indexes them, and makes them searchable. The sourcetype and index fields dictate where and how the data is categorized within Splunk.

The core problem HEC solves is the need for a simple, firewall-friendly way to get data into Splunk without requiring agents installed on every source machine or complex network configurations for traditional TCP/UDP inputs. It leverages standard HTTP/S, making it incredibly versatile for cloud-native applications, IoT devices, or any system that can make an outbound HTTP request.

Internally, HEC works by receiving raw HTTP POST requests. These requests contain the event data, along with metadata like sourcetype, index, and host. Splunk’s HEC endpoint acts as a lightweight web server that queues these incoming events. A dedicated HEC processing thread then picks up these events from the queue and passes them to the Splunk indexing pipeline. This decoupling via a queue is key to its resilience; even if the indexing pipeline is temporarily overloaded, HEC can still accept incoming events.

The key levers you control are:

• HEC Token: This is your API key. It’s essential for authentication and authorization. You create these in Splunk under Settings -> Data Inputs -> HTTP Event Collector.
• URL: The specific endpoint for your HEC. It’s usually https://<your_splunk_host>:8088/services/collector.
• Payload Fields: event (the actual log message), sourcetype, index, host, and time (optional, if you want to override the timestamp).
• Batching: For performance, clients can send multiple events in a single request. The HEC endpoint supports this, significantly reducing network overhead. The payload structure changes slightly to accommodate a list of events.
• Compression: For large volumes, enabling GZIP compression on the client-side can further improve throughput.

When you’re sending data, especially in batches, the time field in the payload is crucial. If you omit it, Splunk will timestamp the event upon ingestion. However, if your events have their own timestamps (e.g., {"event": "...", "time": 1678886400.123}), providing it allows Splunk to ingest the event with its original timestamp, which is vital for accurate chronological analysis. This is especially true for distributed systems where event order matters immensely.

The one thing most people don’t realize is that the HEC endpoint itself has a throughput limit, and it’s not just about your Splunk Search Head or Indexer capacity. If you’re hammering the HEC endpoint with millions of individual requests per minute, even if your Splunk cluster has headroom, the HEC endpoint can become a bottleneck because each individual POST request involves HTTP overhead and queueing. Batching and compression are the primary ways to mitigate this at the HEC layer before data even hits the main indexing pipeline.

The next common hurdle is optimizing your HEC configuration for high-volume, low-latency data streams.