> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sazabi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# WarpBuild

> Turn on WarpBuild's OTLP telemetry export to stream system logs and GitHub Actions logs from your WarpBuild runners to Sazabi.

[All WarpBuild integration capabilities](https://docs.sazabi.com/catalogs/integrations/warpbuild)

## 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](https://www.warpbuild.com/docs/ci/features/observability#exporting-to-your-own-backend), 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.

> [!NOTE]
>
> 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](https://app.warpbuild.com/settings/telemetry)
* 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

**Step 1**

### Open the export form

In WarpBuild, open **Telemetry export** in [Settings](https://app.warpbuild.com/settings/telemetry). Under **Your OTLP backend**, click **Set up** and pick the **Custom (OTLP)** provider.

**Step 2**

### Fill in the form

| Field | Value |
| - | - |
| **Header name** | `Authorization` |
| **Authentication header** | `Bearer <your public key>` (the full `sazabi_public_...` key) |
| **Logs endpoint** | Your intake URL followed by `/v1/logs` |
| **Metrics endpoint** | Leave blank |

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.

**Step 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`](https://www.warpbuild.com/docs/api/org-config/UpdateOrgConfigTelemetryExport) 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](https://docs.sazabi.com/reference/cli.md) (installed and authenticated — see [CLI reference](https://docs.sazabi.com/reference/cli/log-sources.md)).

Registering the source mints the same intake URL the dashboard shows above (the public key is embedded in its hostname):

```bash theme={"system"}
sazabi log-sources create warpbuild --mode manual
```

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](https://docs.sazabi.com/guides/instrument/intake.md) 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](https://docs.sazabi.com/catalogs/log-sources/send-to-an-endpoint/otel-collector.md) log source.

## Further reading

> [card] [Intake](https://docs.sazabi.com/guides/instrument/intake.md)
>
> See per-source ingestion volume and health.

> [card] [Log sources](https://docs.sazabi.com/catalogs/log-sources.md)
>
> Browse the full log source catalog.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.