See how the LoadStrike Datadog sink fits into transaction-aware, self-hosted load testing workflows.
The Datadog integration is the built-in LoadStrike reporting sink for teams that already read logs and metrics in Datadog. The public docs explain what the sink sends, how it can be configured in code or infra config, and which downloadable assets already exist on the site today.
That makes it easier to keep a transaction-aware, self-hosted run while still moving the final reporting events and projected metrics into a familiar observability backend.
Teams that already use Datadog dashboards, queries, or alerting and want LoadStrike run data in the same environment.
Endpoint-only tools often treat backend observability as an afterthought, which leaves the team translating request metrics into downstream stories later. Transaction-aware reporting benefits from a cleaner path into the observability stack the team already uses.
LoadStrike documents Datadog as a built-in reporting sink, includes a downloadable JSON template, and keeps final report files, sink errors, and run metadata attached to the same run artifact that drives the export.
These public assets already exist for the Datadog sink 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 reporting docs describe Datadog as a built-in reporting sink for eligible plans rather than as a custom extension the user has to write first.
Yes. The Datadog route on the public docs links to a downloadable JSON infra-config template along with the shared observability asset guide.
Open the Datadog sink docs, the shared realtime reporting landing page, and the reports overview so the sink-specific behavior is connected back to the broader run artifact and export model.
Keep moving from positioning into concrete product detail.
Use the Datadog sink when your team already reads events and metrics in Datadog. This page explains what LoadStrike sends there and how to configure it.
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 k6 across code ergonomics, protocol scope, downstream correlation, reporting depth, browser workflows, and distributed self-hosted execution.
These reporting pages connect the transaction model to the observability systems already documented publicly.
See how the LoadStrike Grafana Loki sink fits into transaction-aware reporting and public Grafana starter assets.
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 a workload category that often benefits from Datadog exports.
Connect multi-node runs to the observability backend.
Open the docs and sample-repo entry points tied to the same sink 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().
