Skip to main content
All WarpBuild integration capabilities

​
About

WarpBuild’s collector on each runner gathers the runner’s system logs and the GitHub Actions logs of the job it runs. With telemetry export, WarpBuild also sends that telemetry to an OTLP backend you own. Point the export’s logs endpoint at your Sazabi intake URL and every runner sends its logs to Sazabi from its next job on. The export is one organization-wide setting in the WarpBuild dashboard: no agent, collector, or workflow change is needed, and WarpBuild’s own dashboards keep working because the two destinations are independent.
WarpBuild only collects telemetry for jobs that run longer than about a minute, and collects nothing while observability is paused for the organization.

​
Prerequisites

  • A WarpBuild organization running GitHub Actions jobs on WarpBuild runners
  • Access to Telemetry export in the WarpBuild settings
  • Your Sazabi intake URL, shown above — open the log source and copy the Intake URL from its setup screen (the public key is embedded in the URL)

​
Set up in the dashboard

1

​
Open the export form

In WarpBuild, open Telemetry export in Settings. Under Your OTLP backend, click Set up and pick the Custom (OTLP) provider.
2

​
Fill in the form

WarpBuild uses the logs endpoint as-is, so it must end in /v1/logs. WarpBuild encrypts the header value at rest and passes it to the runner’s collector through the environment instead of writing it to disk.
3

​
Turn on the export

Click Turn on export, then Test. Test sends a small OTLP payload from WarpBuild to the endpoint and shows the response. Runners pick up the change on their next job; jobs already running are unaffected.
To script it instead, the same settings are fields of WarpBuild’s PUT /organization/config/telemetry-export API: provider (custom), auth_header_name, secret, and logs_endpoint.

​
Set up with the CLI

You can also register the WarpBuild log source with the Sazabi CLI (installed and authenticated — see CLI reference). Registering the source mints the same intake URL the dashboard shows above (the public key is embedded in its hostname):
The command prints the intake URL for the new source. Add /v1/logs to it for WarpBuild’s Logs endpoint. Run sazabi log-sources get <log-source-id> at any time to reprint the endpoint, or sazabi log-sources list to see every log source in the project.

​
Verify

Run a GitHub Actions job that lasts longer than about a minute on a WarpBuild runner. Open the Intake page in the Sazabi dashboard and confirm records from the WarpBuild source appear within a few minutes.

​
Troubleshooting

Test fails with 401 or 403 — Check that Header name is Authorization and the value is Bearer, one space, then the full sazabi_public_... key. Test fails with 404 — The logs endpoint is missing /v1/logs. Test succeeds but no records arrive — The export applies to jobs that start after it was turned on, and jobs shorter than about a minute aren’t collected. Also check that observability isn’t paused for the WarpBuild organization. Also sending to another backend — WarpBuild exports to one OTLP backend. To fan out, point the export at an OpenTelemetry Collector and use the OpenTelemetry Collector log source.

​
Further reading

Intake

See per-source ingestion volume and health.

Log sources

Browse the full log source catalog.