GitHub Copilot Adds OpenTelemetry Tracing for Coding Agents

Your coding agent just refactored a service, ran three tools, and opened a PR, and you have no idea what happened in between. That's the gap GitHub just closed.

On September 22, GitHub shipped OpenTelemetry (OTel) support in the GitHub Copilot app, letting admins route agent session traces to their own monitoring stack instead of trusting Copilot's own UI to tell the whole story. It extends a capability GitHub had already brought to VS Code and Copilot CLI back in July, and now the desktop Copilot app gets the same treatment.

What GitHub Copilot's OpenTelemetry support actually captures

Once enabled, Copilot exports three kinds of signals from every agent session:

• Traces: hierarchical span trees built from invoke_agent, chat, execute_tool, and execute_hook spans, so you can follow exactly which tool calls happened inside which agent turn.
• Metrics: operation duration, token usage, and tool call counts.
• Events: inference details, session starts, tool calls, and user feedback.

What you don't get by default is the interesting part: prompt and response content is excluded unless an admin explicitly turns on a captureContent flag. That's a sane default for anything touching customer code or regulated data, but it also means your traces will show that a tool ran without showing what it was asked to do, until you decide otherwise.

Turning it on for an org

Admins configure a telemetry block in managed-settings.json, and it can be delivered through native MDM (Windows Registry or macOS managed preferences), a server-managed policy tied to the signed-in GitHub account, or a plain file on disk:

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.<your-domain>.com:4318",
    "protocol": "http/protobuf",
    "captureContent": false,
    "lockCaptureContent": true,
    "serviceName": "github-copilot-agent",
    "resourceAttributes": {
      "deployment.environment": "production",
      "team": "platform-eng"
    },
    "headers": {
      "Authorization": "Bearer <your-otlp-token>"
    }
  }
}

A few things worth knowing before you ship this:

• headers are applied only to Copilot's own OTLP exporter and are never passed through environment variables, specifically so credentials can't leak into subprocesses the agent spawns.
• The agent host computes its telemetry config at startup. Change a managed value and nothing happens until the user reloads the app or editor.
• lockCaptureContent stops individual developers from flipping content capture on locally, which matters if legal or security owns that decision, not the engineer debugging a failed run.

GitHub's own demo routes traces into Splunk Observability Cloud, but since it's standard OTLP, any collector that speaks OpenTelemetry, Honeycomb, Datadog, Grafana Tempo, your own collector in front of an S3 bucket, works the same way.

Why this matters for shipping agents into production

Agentic coding tools have been a black box in exactly the place where black boxes hurt most: your release process. When a Copilot agent edits five files and runs your test suite before opening a PR, "it worked" or "it didn't" isn't enough information when something breaks in review or, worse, after merge. You want to know which tool calls it made, in what order, and how long each step took, the same way you'd want a trace for any other service in your stack.

This also means agent activity can finally sit next to your existing observability data instead of living in a separate silo. If your CI pipeline, your APM, and your Copilot agent all emit OTel, you can correlate a slow or wrong PR back to a specific tool call without cross-referencing three different dashboards.

What to do Monday morning

If your org runs Copilot at scale, don't wait for an incident to figure out tracing. Stand up (or point at) an OTLP collector, add the telemetry block to your managed-settings.json, and leave captureContent off until security has signed off on what capturing prompts and responses means for your compliance posture. Then wire the traces into whatever dashboard your on-call team already watches, so agent runs stop being the one thing in your stack nobody can debug after the fact.

Treating your coding agents like production services, with traces, not vibes, is what separates a pilot from something you can actually hand over to a team that has to support it.