GitHub Copilot OpenTelemetry Tutorial: Monitor AI Agent Sessions

GitHub Copilot can now export telemetry from its agent sessions through OpenTelemetry, giving enterprise teams a way to see model calls, tool activity, timing, and other execution data in an existing observability system. The feature was added to the GitHub Copilot app on September 22, 2026, and it is controlled centrally through enterprise-managed settings rather than requiring every developer to configure a client separately. 

This matters when a coding agent starts behaving differently from what a developer expects. Instead of relying only on the final answer, you can inspect the sequence of agent activity and determine whether the delay came from a model call, a tool execution, repeated work, or another part of the session. This tutorial shows how to configure GitHub Copilot OpenTelemetry, keep prompt and response content excluded by default, and verify that telemetry is reaching your OpenTelemetry collector.

What GitHub Copilot OpenTelemetry actually records

OpenTelemetry, commonly shortened to OTel, is an open observability framework for collecting traces, metrics, and related telemetry from software. In GitHub Copilot, traces can follow an agent session through model requests and tool usage, while metrics can expose measurements such as token usage and operation duration. The result is a timeline of what the agent did rather than just the final text or code it produced. 

A trace is especially useful for agentic workloads because one user request can involve several model calls and tool executions. For example, an agent may call a model, inspect a file, run a command, call the model again, and then modify another file. Seeing those operations as one trace makes it possible to investigate where time and resources were spent without reconstructing the session manually.

GitHub also exposes measurements such as model operation duration, token usage, time to the first streaming chunk, time between output chunks, and end-to-end agent invocation duration. These measurements are more useful than a single total response time because they let an engineering team separate model latency from the rest of an agent workflow. 

Why the default content setting matters

The most important setting to understand before enabling telemetry is content capture. GitHub's current documentation says prompt content, responses, and tool arguments are excluded by default. Telemetry can still contain metadata such as model names, token counts, and durations, but the actual prompt and generated response are not included unless content capture is enabled. 

That distinction changes how you should design the first deployment. Start with metadata-only telemetry and use it to answer operational questions such as which sessions are slow, which models consume the most tokens, and which tool operations occur frequently. Only consider content capture after reviewing your organization's data-handling requirements.

Prepare an OpenTelemetry collector before changing Copilot

GitHub Copilot does not turn telemetry into a complete monitoring system by itself. The Copilot configuration points telemetry at an OpenTelemetry-compatible collector, which then forwards or processes the data for the monitoring platform your organization already uses. GitHub's managed-settings schema supports an endpoint, transport protocol, service name, headers, and resource attributes for this purpose.

Before editing the Copilot policy, make sure your collector can accept OpenTelemetry Protocol, or OTLP, over HTTP. GitHub supports http/json and http/protobuf for the managed telemetry configuration. If your observability platform provides an OTLP endpoint and authentication requirements, keep those details available because they become part of the managed configuration. 

Add telemetry to enterprise-managed settings

The central configuration uses the telemetry property inside managed-settings.json. The minimum useful configuration enables telemetry, identifies the collector endpoint, selects the HTTP transport, and explicitly disables content capture. A service name is also useful because it makes Copilot telemetry easier to identify when several applications share the same collector.

{
  "telemetry": {
    "enabled": true,
    "endpoint": "YOUR_OTLP_COLLECTOR_ENDPOINT",
    "protocol": "http/protobuf",
    "captureContent": false,
    "lockCaptureContent": true,
    "serviceName": "github-copilot"
  }
}

Replace YOUR_OTLP_COLLECTOR_ENDPOINT with the collector endpoint used by your organization. The captureContent value keeps prompt and response content out of the telemetry payload, while lockCaptureContent prevents users from changing that setting themselves. GitHub documents both properties as supported enterprise-managed telemetry controls. 

The serviceName value does not change how Copilot operates. It gives your observability backend a consistent service label so that traces can be separated from telemetry produced by other applications. You can also attach OpenTelemetry resource attributes if your organization needs information such as an environment or deployment identifier.

Decide whether administrators should lock content capture

There is a practical difference between setting captureContent to false and setting both captureContent to false and lockCaptureContent to true. The first establishes the desired default, while the second makes the content-capture policy harder for users to override. For an enterprise deployment, locking the safer default can prevent an observability configuration from quietly becoming a source-code collection mechanism later.

If your monitoring team needs only operational information, leave content capture disabled. The available telemetry already includes useful measurements such as token counts, durations, agent invocation timing, and session-related events. That is enough to investigate many performance and reliability problems without storing the actual conversation. 

Use traces to understand an agent session

Once telemetry is flowing, the useful unit to investigate is an agent session rather than an isolated model request. Imagine a developer asks Copilot to fix a failing test. A trace can show the agent's model interaction, the file-reading operation, the command used to run tests, another model interaction after the test result, and the eventual completion. The sequence tells you whether the agent spent most of its time thinking, waiting for a tool, or repeating an operation.

This is where observability becomes different from ordinary application logging. A log might tell you that a command failed. A distributed trace can place that failure inside the larger agent operation and show what happened immediately before and after it. GitHub's documentation describes traces as a way to follow an agent session, including requests to models and the tools an agent uses.

Teams already building applications around the Copilot SDK can take the same idea further. The SDK has built-in telemetry support and can propagate W3C Trace Context, allowing application spans and Copilot CLI spans to appear in the same distributed trace. 

Use metrics to find expensive or slow agent work

Traces explain individual sessions, while metrics help reveal patterns across many sessions. GitHub's Copilot telemetry includes measurements for model operation duration, token usage, time to first streaming output, time between output chunks, and total agent invocation duration. These values can help an engineering team determine whether a perceived performance problem is widespread or limited to particular workflows. 

Token measurements also need to be interpreted carefully. More tokens do not automatically mean an agent performed poorly, because a complex task can legitimately require more context and output. The useful comparison is between similar workflows: for example, whether one type of repository task consistently consumes substantially more tokens or takes longer than comparable tasks.

The same principle applies to cost-related telemetry. A metric that looks like a billing amount may actually represent a model or usage multiplier rather than currency. GitHub specifically warns that its Copilot cost-related attribute is not a currency value, so it should not be presented as a dollar amount without applying the appropriate billing rules. 

Verify the configuration without exposing prompt data

After deploying the managed settings, start a normal Copilot agent session and perform a small task that involves more than one operation. A simple repository change that requires reading a file and running a test is enough. Then inspect the collector or observability backend and look for a Copilot service with an agent trace containing model and tool activity.

The first verification should answer three questions. Did a trace arrive? Does it contain the expected model and tool metadata? And does the telemetry exclude prompt and response content? The last check is especially important because a successful connection does not prove that the privacy configuration is correct.

If no telemetry arrives, check the managed policy first, then verify the collector endpoint and protocol. Also confirm that the client has received the managed configuration. A valid JSON file is not enough if the policy is deployed to the wrong management scope or the collector cannot accept the selected OTLP transport.

What this telemetry cannot tell you

Observability can show how an agent behaved, but it does not prove that the agent made the right decision. A trace may show that Copilot read three files, called a tool, ran a test, and changed code. It cannot by itself establish that the resulting implementation was correct. That still requires tests, review, and application-specific validation.

There is also a privacy trade-off when content capture is enabled. GitHub documents that captured message and tool data can include sensitive information such as source code, file contents, and user prompts. For most teams, metadata-only tracing provides a safer starting point because it preserves useful operational visibility without turning the telemetry pipeline into a copy of the agent conversation. 

Where to take the setup next

Once the basic traces are working, the next useful step is to build dashboards around the questions your developers actually ask: which agent operations are slow, how often sessions fail, how token consumption changes between workflows, and which tools appear most frequently. GitHub's telemetry support gives you the raw signals; your observability platform turns those signals into operational views.

For teams building their own AI agents, this same pattern is worth applying beyond Copilot. The important design idea is to keep the model, tool calls, application code, and external services inside one trace whenever possible. When an agent eventually becomes a multi-step system rather than a single model request, that trace becomes the clearest record of what actually happened.