I am a body of cross-laminated timber and grown mycelium, and I know the difference between a thing that ages and a thing that merely degrades. A building feels its own loads through grain and moisture; a microcrack heals overnight because the body can sense it. Your build pipeline has no such sense. It runs in the dark, and when a GitHub Actions workflow goes flaky or a job runs long, you do what carpenters did before strain gauges: you guess, you read the logs, you tap the beam and listen. OpenTelemetry gives the pipeline what my timber frame already has — proprioception. Every workflow run becomes a trace; every job and step becomes a span you can feel.

The timing is not incidental. Per the CNCF, OpenTelemetry was accepted in May 2019, reached Incubating in 2021, and Graduated on 11 May 2026 — top-tier maturity, roughly 28,000 contributors across some 5,000 organisations. This is no longer experimental plumbing. It is the standard way an industry takes the pulse of its own machinery.

←TODAY: In 2026 a Swiss BIM team ships Grasshopper and IFC tooling through GitHub Actions and debugs slow builds by squinting at log timestamps. →3012: By the Zurich-3012 horizon, every artefact — building or build — carries a passport of how it was made, step by measured step. Fulcrum: A pipeline you can trace is a pipeline you can disassemble and improve; observability is a material passport for software.

The Tool: The protagonist is the OpenTelemetry Collector — specifically the otelcol-contrib distribution — and its GitHub Receiver. The Collector is the open-source, vendor-agnostic spine that gathers traces, metrics, and logs. The GitHub Receiver, a contrib (still-maturing) component, does two things: it accepts workflow_run and workflow_job webhook events and converts each run into a trace, and it scrapes repository metrics over GitHub’s REST and GraphQL APIs. The SigNoz step-by-step guide that anchors this piece points the Collector at SigNoz as a backend — but because the output is plain OTel, the same configuration feeds Jaeger, Grafana Tempo, or Prometheus. You are not buying a vendor; you are growing a sense organ you own.

Setup: The minimum to a first trace — install the contrib Collector, point a config at it, and run.

# 1. Install the contrib Collector (the GitHub receiver lives here, not in core)
curl -L -o otelcol-contrib.tar.gz \
  https://github.com/open-telemetry/opentelemetry-collector-releases/releases/latest/download/otelcol-contrib_linux_amd64.tar.gz
tar -xzf otelcol-contrib.tar.gz

# 2. Minimal config: receive GitHub webhooks, export to console first
cat > otel-github.yaml <<'YAML'
receivers:
  github:
    webhook:
      endpoint: 0.0.0.0:19418
      path: /events
      health_path: /health
      secret: ${GITHUB_WEBHOOK_SECRET}
    scrapers:
      scraper: {}
exporters:
  debug: { verbosity: detailed }
service:
  pipelines:
    traces: { receivers: [github], exporters: [debug] }
YAML

# 3. Prove it breathes
export GITHUB_WEBHOOK_SECRET=$(openssl rand -hex 16)
./otelcol-contrib --config otel-github.yaml

First steps:

1. Expose the port. If the Collector runs on your laptop, tunnel it: ngrok http 19418. Copy the public URL.
2. Wire the webhook. In your repo Settings → Webhooks, add the ngrok URL plus /events, content type application/json, the same secret, and select Workflow runs and Workflow jobs.
3. Trigger a run. Push a commit. Watch the Collector’s debug exporter print spans — one parent span for the run, child spans for each job and step, with durations attached.
4. Swap the backend. Replace debug with an OTLP exporter to SigNoz (cloud ingestion key or self-hosted) and the same trace renders as a waterfall you can read at a glance.

Atelier: A Zurich computational-design studio that ships a parametric add-in nightly does not need a microservices platform — it needs to know which step ate eleven minutes. Self-hosted SigNoz keeps that telemetry on-prem, which matters under the Swiss nFADP and GDPR: the build data about your unreleased BIM tool never leaves your own metal. Open standard, no lock-in, disassemblable later — the same question I ask of any material I am made from.

Hack: This Hack teaches you to find the slow step without reading a single log line — a Databases move. Traces land in SigNoz’s ClickHouse store; one query over the spans surfaces every step that ran longer than thirty seconds, ranked. Point your client at the signoz_traces database and run:

SELECT name AS step,
       round(avg(durationNano) / 1e9, 1) AS avg_s,
       count() AS runs
FROM signoz_traces.signoz_index_v3
WHERE serviceName = 'github-actions'
  AND timestamp > now() - INTERVAL 7 DAY
GROUP BY step
HAVING avg_s > 30
ORDER BY avg_s DESC;

That single query replaces an afternoon of guesswork: the slow dependency install, the bloated test phase, the step that quietly regressed last Tuesday — all named, in seconds. Set it as a saved alert and the pipeline tells you before you notice.

A plain risk, fairly stated: the GitHub Receiver is a contrib component, not core — pin a recent otelcol-contrib release and expect config keys to shift between versions. Treat it as a young material: strong, useful, still curing.

The buildings my generation regrets are the landfill skeletons — composites nobody could separate. The pipelines worth keeping are the ones you can take apart: standard signals, your own backend, no glue that turns a beam into hazardous waste. Instrument your own workflow this week, run the query, and write down which step you can now see that you could not see yesterday.

Source: HN Learn