OpenTelemetry support in the GitHub Copilot app, announced on September 22, 2026, allows enterprises to route agent activity data to OTLP-compatible observability tools through managed settings. Before enabling export, the main question is not only which endpoint to use. Teams need to understand which signals will be sent, which settings can expose sensitive content, and how to verify that the policy received by the app matches the current documentation.
What changed in the Copilot app
According to the GitHub changelog, the Copilot app now accepts OpenTelemetry configuration through enterprise-managed settings. The goal is to observe agent execution in monitoring tools already used by the organization, following the flow of a session, model calls, and tool use.
The announcement also emphasizes centralized control. Instead of asking each developer to configure telemetry individually, administrators can define the policy in managed-settings.json. Prompt and response content is excluded by default, making content capture one of the first settings to review before rollout.
What data to watch: traces, metrics, and events
GitHub's conceptual documentation organizes agent telemetry into three signal types. Each answers a different question and they are most useful when analyzed together.
| Signal | What it shows | Documented example | Practical use |
|---|---|---|---|
| Traces | The flow of an agent session and the relationship between its steps. | A model call, followed by use of the readFile tool, and then another model call. | Investigate where a session became slow, took an unexpected path, or executed a particular tool. |
| Metrics | Numeric measurements that can be aggregated over time. | Input and output token usage for model calls. | Identify consumption trends, compare periods, and detect changes in behavior. |
| Events | Individual actions tied to a specific point in time. | An edit feedback event showing whether a user accepted or rejected an agent edit. | Relate user decisions to agent execution and analyze the outcome of specific interactions. |
This map helps avoid an oversimplified view of telemetry. A token spike is a metric; the sequence that led to that consumption appears in traces; and an acceptance or rejection can appear as an event. The observability backend should preserve enough context to correlate these signals without turning every session into captured content.
Sensitive content: the setting that deserves the most attention
By default, the documentation states that prompts, responses, and tool arguments are not included. Content capture can be enabled, but the payload may then contain sensitive information such as code, file contents, and user prompts.
A conservative starting configuration is to keep captureContent disabled and first validate the operational value of traces, metrics, and events without content. If the organization has a clear reason to capture content, the change should be treated as a data-governance decision, with review of backend access, retention, authentication, sharing, and internal security and privacy requirements.
The lockCaptureContent field prevents users from changing the enterprise-defined content-capture setting. This matters when policy must keep content exclusion consistent across teams.
What to configure in managed-settings.json
The changelog directs administrators to configure the telemetry property in the enterprise managed-settings file. The enterprise-managed settings reference documents the following fields for that property:
| Field | Purpose | What to check before enabling |
|---|---|---|
| enabled | Turns telemetry export on or off. | Whether the rollout is a pilot or enterprise-wide and which groups receive the policy. |
| endpoint | Defines the OTLP collector URL. | Availability, TLS, network routing, and ownership of the destination. |
| protocol | Selects transport, with documented values http/json or http/protobuf. | Compatibility with the collector and existing network controls. |
| captureContent | Includes or excludes prompt and response content from the telemetry payload. | Whether content is truly needed and the impact on sensitive data. |
| lockCaptureContent | Prevents users from changing the content-capture option. | Whether the content policy must be mandatory. |
| serviceName | Sets the service name used as an OTel resource attribute. | A naming convention that distinguishes Copilot from other telemetry producers. |
| resourceAttributes | Adds resource attributes to all exported telemetry. | Avoid unnecessary, sensitive, or high-cardinality attributes. |
| headers | Adds HTTP headers to telemetry requests, such as collector authentication. | How secrets are provisioned, protected, and rotated. |
Backend and export flow
GitHub recommends a secure backend that supports the OpenTelemetry Protocol. If the observability platform does not receive OTLP directly, the documentation suggests using an OpenTelemetry Collector to receive, process, and forward the data.
Before enabling clients, test the full path: Copilot app, OTLP endpoint, authentication, collector processing when present, and persistence in the backend. The test should confirm that traces have a useful hierarchy, metrics arrive with expected units and dimensions, and events can be correlated without accidental content exposure.
There is a documentation mismatch right now
The September 22 changelog explicitly states that the GitHub Copilot app gained OpenTelemetry support through enterprise-managed settings. The getting-started guide for managed settings also lists the Copilot app among supported clients and notes that not every client supports every property.
At the same time, the telemetry section of the enterprise-managed settings reference still says, in the documentation checked on September 27, 2026, that this property is supported for Copilot CLI and VS Code. Because the two official pages are not fully aligned, the safest procedure is to treat the changelog as the feature announcement and verify policy application in the Copilot app used by the enterprise before a broad rollout. The announcement does not provide a specific app version number.
How to validate before enterprise-wide rollout
- Start without content. Keep captureContent disabled and confirm whether traces, metrics, and events already answer the team's observability questions.
- Use a controlled test endpoint. Verify authentication, encryption in transit, filtering, and retention rules before pointing clients at production.
- Define consistent identity. Use serviceName and resourceAttributes consistently to separate environment, team, or deployment without adding unnecessary personal data.
- Verify the policy on the client. For server-managed deployments, GitHub says supported clients receive updates in about an hour; restarting the client or signing in again can refresh them immediately.
- Compare the result with the intended policy. Confirm that the app exports to the correct endpoint and that prompt, response, and tool-argument content remains absent when capture is disabled.
- Expand only after the pilot. A limited rollout reduces the risk of discovering volume, cost, cardinality, or privacy issues after distributing the configuration across the enterprise.
What telemetry can and cannot answer
With the signals collected correctly, teams can reconstruct session flow, observe model and tool calls, track token usage, and record selected interaction events. This supports operational investigation, trend analysis, and centralized monitoring.
OpenTelemetry does not decide which data an organization should retain and does not replace security, privacy, or access policies. The technical configuration determines what gets exported; governance determines who can read it, how long it is retained, and under which conditions more sensitive content may be collected.
