Telemetry
Send every workflow run to your observability tool as an OpenTelemetry trace.
Each workflow run can go to your observability tool as a trace: the run, its jobs and their steps, with where each job ran and how long it waited for a runner. Traces use the OpenTelemetry format and its CI/CD conventions, so Honeycomb, Grafana, Axiom or your own OpenTelemetry Collector can read them without setup.
Every job in your connected repos is included, whichever runner took it.
Set up
Section titled “Set up”- Open Settings → Telemetry. Owners and admins can change it.
- Pick where to send traces, or choose Other and paste any endpoint that accepts OTLP over HTTP with JSON. Traces go to the endpoint’s
/v1/traces. - Add the headers your tool wants, usually an API key. Values are stored encrypted and never shown again.
- Save, then click Send test trace. A trace named
RUN RelayRunner testshows up in your tool.
From then on, each job goes out when it finishes and each run when it completes.
| Span name | Description | When sent |
|---|---|---|
RUN {workflow} |
The run attempt, from when it started to when it completed. The root of the trace. | When the run completes |
{job name} |
One job, from when GitHub queued it to when it finished. | When the job finishes |
Waiting for a runner |
The time between GitHub queuing the job and a runner taking it. | With its job |
{step name} |
One step of the job. Skipped steps are left out. | With its job |
Failed runs, jobs and steps have an error status and an error.type.
Ids come from GitHub’s run and job ids, so a job sent early and its run sent later land in the same trace.
Attributes
Section titled “Attributes”The run span:
cicd.pipeline.name,cicd.pipeline.run.id,cicd.pipeline.run.url.full,cicd.pipeline.resultvcs.ref.head.name,vcs.ref.head.revision,vcs.change.id(the pull request number)relayrunner.run.attempt,relayrunner.run.event(push, pull_request and so on),relayrunner.run.title,relayrunner.run.actorrelayrunner.routed: whether the run went through the Routerrelayrunner.route.providerandrelayrunner.route.skipped: where the Router sent it, and what it passed over and whyrelayrunner.retry: whether this attempt was an automatic retry
Each job span:
cicd.pipeline.task.name,cicd.pipeline.task.run.id,cicd.pipeline.task.run.url.full,cicd.pipeline.task.run.result,cicd.worker.namerelayrunner.provider: where it ran, such asmachine,githubordepotrelayrunner.runner: the machine’s name or the runner typerelayrunner.labels: the job’sruns-onlabelsrelayrunner.queue.wait_msandrelayrunner.billed_minutesrelayrunner.cpu.p95,relayrunner.memory.p95_mb,relayrunner.cpus,relayrunner.memory_mb: on machines that report usage
The resource carries service.name (github-actions unless you change it), vcs.repository.name, vcs.repository.url.full and vcs.owner.name.
When sending fails
Section titled “When sending fails”If your endpoint is down or rate limiting, sending retries for about an hour. If it refuses the key, the error shows in Settings → Telemetry. After three days of nothing but errors, sending pauses until you save the settings again.
What gets sent
Section titled “What gets sent”Repository and workflow names, branches, commit SHAs, pull request titles, GitHub usernames, job and step names, timings and where each job ran. Never logs, secrets or environment variables.