---
title: "Comment by Amit Malhotra on \"Distributed Tracing for CI Pipelines Without Touching a Single Workflow File\" | Hashnode"
description: "This is a great example of where platform-level instrumentation can remove a lot of friction from engineering teams. Getting end-to-end visibility across CI pip"
url: "https://hashnode.com/posts/distributed-tracing-for-ci-pipelines-without-touching-a-single-workflow-file/6a771f53e42cf22dee8376a1/comment/6a7bf836ad2d3766418d40d8"
---

[Discussion](https://hashnode.com/posts/distributed-tracing-for-ci-pipelines-without-touching-a-single-workflow-file/6a771f53e42cf22dee8376a1)

Comment [Distributed Tracing for CI Pipelines Without Touching a Single Workflow File](https://hashnode.com/posts/distributed-tracing-for-ci-pipelines-without-touching-a-single-workflow-file/6a771f53e42cf22dee8376a1)

[Amit Malhotra](https://hashnode.com/@vertro-io)

[Aug 12](https://hashnode.com/posts/distributed-tracing-for-ci-pipelines-without-touching-a-single-workflow-file/6a771f53e42cf22dee8376a1/comment/6a7bf836ad2d3766418d40d8)

This is a great example of where platform-level instrumentation can remove a lot of friction from engineering teams. Getting end-to-end visibility across CI pipelines without asking every team to modify and maintain workflow files is a much more scalable approach.

The real value is making observability part of the platform rather than another responsibility for individual developers.

[George Sims](https://hashnode.com/@george-sims)

[Aug 12](https://hashnode.com/posts/distributed-tracing-for-ci-pipelines-without-touching-a-single-workflow-file/6a771f53e42cf22dee8376a1/comment/6a7bf836ad2d3766418d40d8#reply-6a7c25115552d33e3f72aa09)

Hi Amit, exactly, that's the real shift here. Once observability sits at the platform level instead of being something every team has to remember to add, it stops being a "did we remember" problem and just becomes enabled by default. The OpenTelemetry Collector is what makes that practical for something as varied as CI tooling: it's language-agnostic, so it doesn't matter what a team's workflow is written in, and receivers like the one this post covers mean a new telemetry source can be added without asking anyone to touch their own code. Teams can even contribute their own receiver to the OSS project if there's a source that doesn't exist yet.

[Amit Malhotra](https://hashnode.com/@vertro-io)

[Aug 17](https://hashnode.com/posts/distributed-tracing-for-ci-pipelines-without-touching-a-single-workflow-file/6a771f53e42cf22dee8376a1/comment/6a7bf836ad2d3766418d40d8#reply-6a8304ff0ead75fc196270a6)

Exactly. The “enabled by default” part is what makes this approach really scalable.

And I think there's another benefit: once telemetry is standardized at the platform level, teams can spend their time interpreting the signals rather than figuring out how to generate them.

That shift—from instrumentation as a team responsibility to observability as a platform capability—is where the real leverage comes in.