OpenTelemetry

This page covers RunsOn metrics end to end: the per-job runner metrics you get in the GitHub Actions UI, and the authoritative OpenTelemetry reference for Flex and Fleet — what each product emits, when, and where the automatic behavior stops.

At a glance#

RunsOn surfaces per-job resource metrics (CPU, memory, disk, network, I/O) through three paths, from zero-config inline charts to full OTLP export. Server-side control-plane signals go out over OTLP only.

These are not mutually exclusive — a job can render inline charts and export to OTLP at the same time.

Per-job runner metrics#

Use these to rightsize runners and spot job-level constraints without leaving the GitHub Actions UI.

Built-in inline charts#

This is the default path on current RunsOn runners:

1. The runner collects local host metrics during the job.
2. RunsOn writes those samples into metrics.jsonl on the runner.
3. The Complete runner step renders ASCII charts from that file.
4. The same step uploads metrics.jsonl into your RunsOn S3 bucket for later inspection.

This flow is separate from remote OTLP export — you get the Complete runner charts and the uploaded metrics.jsonl file without enabling extras=otel.

Runner metadata#

For each runner you also get detailed metadata about the EC2 instance, RunsOn installation, and runner timings — expand the “Set up job” section in the GitHub Actions UI:

Control-plane behavior#

When an OTLP endpoint is configured, Flex and Fleet export OTLP logs, metrics, and traces from their control planes. Flex uses service.name=runs-on-flex; Fleet uses service.name=runs-on-fleet. Both emit the unified RunsOn server-metrics catalog below, structured operator logs, and Go runtime metrics.

Current v3 installs do not expose a Prometheus /metrics endpoint. Use the product’s OTLP endpoint setting for server-side metrics: OtelExporterEndpoint for Flex CloudFormation, or otel_exporter_endpoint for Flex and Fleet Terraform.

Runner-side behavior#

Runner-side OTEL behavior is available on Flex starting with RunsOn v2.12.0.

When the stack has an OTLP endpoint configured and a job opts in with extras=otel, the runner exports its host metrics (CPU load and utilization, memory, disk I/O, network I/O) and Go-runtime metrics to your observability backend, alongside the per-step job spans. Add extras=otel to a job label, or to the runner spec used by a pool:

runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64/extras=otel

• The collector always writes local metrics.jsonl for the built-in inline charts, independent of OTLP — enabling one does not require the other.
• Remote OTLP export only happens when the runner has OTEL enabled and the stack OTLP endpoint is configured.
• RunsOn exports the same core runner host-metric set on Linux and Windows, with platform-specific device and mount filtering.
• Fleet does not expose extras=otel. Its OTLP configuration observes fleetd and Fleet job lifecycle signals rather than individual runner-host metrics.

Datadog resource attributes as tags#

RunsOn adds runner identity and context as OTLP resource attributes, including service.instance.id, stack_name, region, org, instance_type, and repo_full_name. When exporting directly to Datadog’s OTLP endpoint, ask Datadog to promote those resource attributes into metric tags:

otel_exporter_temporality = "delta"
otel_exporter_headers = "dd-api-key=<dd-key>,dd-otel-metric-config=${jsonencode({ resource_attributes_as_tags = true })}"

OtelExporterTemporality: delta
OtelExporterHeaders: dd-api-key=<dd-key>,dd-otel-metric-config={"resource_attributes_as_tags":true}

Without resource_attributes_as_tags, Datadog can receive the metrics while hiding useful runner context such as the EC2 instance id from metric tag filters.

Logs#

When the stack OTLP endpoint is configured, RunsOn exports control-plane logs from Flex or Fleet. Terraform enables log export by default through otel_logs_enabled; logs also remain available in CloudWatch through the usual AWS log groups.

RunsOn forwards the runner bootstrap log file (output.log) through the local collector when runner OTEL is enabled.

This is the RunsOn bootstrap and agent log path. It is not the full GitHub workflow job log stream.

If the EC2 instance log group is configured, the same bootstrap log file also remains available through the instance log group path in CloudWatch.

Traces#

RunsOn emits control-plane traces plus agent and instance lifecycle traces. Terraform enables control-plane trace export by default through otel_traces_enabled.

Flex also emits per-step job spans automatically after a job completes. Those spans are emitted from the Flex control plane, and you don’t need to set extras=otel on jobs to get them.

v3.2 operator telemetry#

v3.2 gives Flex and Fleet one operator metric and structured-event contract. Configure the control-plane exporter on either Terraform module with the same inputs:

otel_exporter_endpoint    = "https://your-otlp-endpoint"
otel_exporter_headers     = "authorization=<token>"
otel_exporter_temporality = "cumulative"
otel_logs_enabled         = true
otel_traces_enabled       = true

Use the authentication header format required by your backend, and keep it in your normal secret-management path. For a Flex CloudFormation stack, use OtelExporterEndpoint, OtelExporterHeaders, and OtelExporterTemporality instead.

Update existing dashboards and alerts#

Update queries that use the previous Flex-only contract:

The first Fleet maintenance pass after rollout can replay one in-flight lifecycle event from an older claim. Structured events have deterministic event_id values for deduplication; OTLP job counters can show a one-time bump.

Cost estimates and structured events#

runs_on_job_estimated_cost_usd is an operational estimate, not an AWS bill. It includes EC2 compute plus live root and sticky EBS usage. Retained sticky snapshots are exported separately as runs_on_sticky_snapshot_estimated_cost_usd_per_hour; that value is an hourly upper bound based on full volume size, while AWS bills only changed EBS blocks.

If pricing or durable launch inputs are incomplete, RunsOn omits a cost estimate rather than recording zero. Use runs_on_job_cost_estimate_coverage and runs_on_pool_cost_estimate_coverage before treating cost charts as representative.

For a ready-made Flex and Fleet view, import the SigNoz operator dashboard. It uses job_launched, job_summary, operator_snapshot, and spot_interruption alongside the OTLP metrics.

Reference: metric inventory#

RunsOn server metrics#

Runner host metrics exported to OTLP by default#

Notes:

• Remote OTLP export requires extras=otel, a configured OTLP endpoint, and JobEnabled=true.
• Applies to Linux and Windows.
• On Linux, disk I/O covers detected whole devices, including additional instance-store disks; filesystem utilization covers the root, sticky-disk, and runner tmpfs mount points.
• On Windows, disk I/O covers fixed drive-letter volumes and filesystem utilization covers the root volume. Directory-mounted sticky disks are not exposed by the Windows scrapers.
• Network metrics are limited to the detected primary network interface.

Go runtime appendix#

Reference: attribute inventory#

RunsOn server metric attributes#

RunsOn server resource attributes#

Runner metric attributes exported to OTLP by default#

Runner resource attributes#

Go runtime metric attributes#