Product1 publisher3 min readPublished
One org-level webhook turns every GitHub Actions run into a trace you can drill into
A CNCF walkthrough routes workflow_run and workflow_job events into an OpenTelemetry Collector, so CI coverage depends on org admin access rather than on who remembered to add a tracing step.
The Product Desk · Product desk
What happened
- A CNCF walkthrough puts an OpenTelemetry Collector running the githubreceiver behind a single org-level GitHub webhook, converting workflow_run and workflow_job events straight into OTLP spans.
- The spans nest the way the pipeline does, with the workflow run as the outer span, each job a child of it and each step a child of the job, so a slow run can be drilled into.
- GitHub's built-in insights are per-repo and shallow: they give no cross-org view of CI health, no slicing by team or workflow type, and no alerting when pipelines quietly get worse.
- The githubreceiver is a contrib component still at alpha stability, so the post tells readers to pin a collector version and skim the changelog before bumping it.
- The collector config will not validate without at least a dummy scrapers entry, even when tracing through the webhook is the only thing the team wants.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- constraint Rollout needs a single org admin approval rather than a per-team negotiation, so the platform engineer who wants the data cannot ship it alone; the project depends on that one approval happening.
- exposure A public endpoint that accepts GitHub deliveries becomes production perimeter the platform team owns, so CI visibility inherits whatever allowlisting and WAF discipline that team already practises.
- decision With OTLP on the wire, the choice between Tempo, Jaeger and Datadog stays reversible, which moves the real commitment onto operating a collector rather than onto a vendor contract.
The CNCF post opens on the moment that gives the problem away: someone asks why CI took forty minutes yesterday, and the honest answer is "let me go check that one repo and get back to you" [1]. What teams tell themselves about that gap is that instrumentation is a one-time ask, that the tracing step goes into the shared template and quietly propagates from there. What the post says happens instead is that every team has to opt in, every new repo starts blind until someone remembers, and the instrumentation ends up spread across however many workflow files the org has accumulated [14].
Coverage under that model is the set of repos where somebody remembered and nobody later removed the step, which is a smaller and less predictable number than every repo in the org [1]. The arithmetic on setup runs the same way. One collector and one org webhook is a fixed cost that does not move when the repo count does, while per-workflow instrumentation is one edit per workflow file and grows with the org [2].
Some grit in the config is worth knowing before Monday. The scrapers stanza that the tracing pipeline never uses belongs to a separate GraphQL and REST metrics feature the same receiver offers, which is why it reads as irrelevant, and the post puts the cost of finding that out at roughly twenty minutes [8][9]. If rotating a shared secret across many services is already a chore, there is a GitHub App path instead of managing the secret directly [11].
The detail I would not skip is the deterministic IDs. Span and trace IDs are hashed from the workflow's run ID and each job's check run ID, so a team that genuinely wants custom telemetry from inside a step can compute the matching ID and attach to the same trace with no coordination with the collector [6]. That makes in-workflow instrumentation additive rather than the baseline, which is the right order for it. And since nothing was added to any workflow file [15], a collector outage costs you spans rather than red builds [3].
The evidence stops at mechanism. There is no before-and-after on queue times or flake rates, and no figure for span volume or the backend bill that volume produces [16]. The test that separates the two approaches in your own org is whether a repo created tomorrow shows up in the CI view without anyone being told it exists, and whether the answer to "who owns this when an alpha config field changes shape" is a name rather than a team. Per-repo instrumentation answers the first with "whoever remembered", which is how you end up checking one repo at a time again.
What to watch
- githubreceiver graduating to beta or stable, which would let teams track collector releases instead of freezing one.
- Any sign GitHub extends its own insights into an org-level CI health view, which removes the reason to run a collector.
- Whether the receiver's separate scraper metrics feature matures enough that teams keep it rather than filling it with a dummy entry.