See how the LoadStrike Splunk HEC sink fits into transaction-aware reporting workflows.
The Splunk HEC integration is the built-in LoadStrike reporting sink for teams that already route observability data through Splunk. The public site documents the configuration surface and publishes a ready-to-edit JSON template for the sink.
That makes it easier to keep transaction-aware LoadStrike runs self-hosted while still exporting reporting events and projected metrics to a backend the team already uses operationally.
Teams already using Splunk HEC for logs or event flows and wanting LoadStrike run data in the same environment.
Request-only reporting loses value when the important signal is the transaction that finished late or failed downstream. That signal becomes more useful when the final run artifact also has a clean path into the team’s existing observability workflow.
LoadStrike documents Splunk HEC as a built-in sink, supports code or infra-config setup, and publishes a downloadable JSON template plus the shared observability asset guide.
These public assets already exist for the Splunk HEC workflow.
Read the sink behavior and configuration surface.
Download the ready-to-edit infra config template.
Open the shared guide that groups the public assets.
These questions are rendered on the page and mirrored in the matching FAQ structured data when the route is indexable.
Yes. The public docs describe Splunk HEC as a built-in reporting sink for eligible plans and explain how the sink is configured.
Yes. The public downloads include a Splunk HEC JSON template plus the shared observability asset guide.
Open the Splunk HEC sink docs, the realtime reporting landing page, and the reports overview so the sink-specific workflow stays connected to the full transaction run artifact.
Keep moving from positioning into concrete product detail.
Use the Splunk HEC sink when you want LoadStrike reporting events and projected metrics delivered through Splunk.
Realtime reporting streams LoadStrike data to external backends during the run and again when the run finishes.
This page explains how to read a LoadStrike report. Use it when you want to know what each section means and where to look first.
Use these routes when the next question is tool choice rather than implementation detail.
Compare LoadStrike and Apache JMeter across scenario design, protocol coverage, downstream correlation, browser workflows, reporting, and self-hosted operations.
These reporting pages connect the transaction model to the observability systems already documented publicly.
See how the LoadStrike Datadog sink fits into transaction-aware, self-hosted load testing workflows.
See how the LoadStrike OTEL Collector sink fits into OpenTelemetry-oriented reporting workflows.
Every published route should help you move to the next concrete question instead of ending in a dead end.
See how cluster runs still land in one reporting story.
Return to the workload model behind the sink export.
Open the docs and sample-repo entry points tied to the same reporting story.
Open the sink-specific docs, start with the downloadable assets that already exist in the public site, and keep the reporting path aligned with the same run artifact that LoadStrike returns from Run().
