GitHub has announced OpenTelemetry support for the GitHub Copilot app through enterprise-managed settings. The capability allows enterprise administrators to export Copilot agent telemetry to an OTLP-compatible observability platform or to an OpenTelemetry Collector.
For teams operating Copilot at organizational scale, the change provides a central way to examine agent sessions, model requests, tool activity, token-usage measurements, and user responses to agent edits. It also introduces an important data-governance decision: content capture is optional, and enabling it can expose code, file contents, and prompts to the receiving telemetry system.
What changed
The September 22, 2026 announcement describes OpenTelemetry export for the GitHub Copilot app. Administrators configure the feature in managed-settings.json by adding a telemetry object.
The enterprise-managed settings reference documents fields for enabling telemetry, selecting an endpoint and protocol, controlling content capture, naming the service, adding resource attributes, and supplying headers. The documented example uses an HTTPS OTLP endpoint, the http/protobuf protocol, and an Authorization header containing a Bearer token.
GitHub’s OpenTelemetry documentation says the exported data can include traces, metrics, and events. These signals can represent an agent session, model calls or requests, tool use, token-usage measurements, and whether users accept or reject agent edits.
How the configuration fits together
The documented managed-settings example includes the following configuration concepts:
enabledturns telemetry export on or off.endpointidentifies the OTLP destination.protocolselects the documented transport format, including the example valuehttp/protobuf.captureContentcontrols whether content is included in telemetry.lockCaptureContentcan prevent users from changing the content-capture setting.serviceNamesupplies the service identity, with the example usingcopilot.resourceAttributesadds identifying attributes to the exported data.headerssupplies request headers such as the documented Bearer authorization example.
A simplified version of the documented structure looks like this:
{
"telemetry": {
"enabled": true,
"endpoint": "https://observability.example/otlp",
"protocol": "http/protobuf",
"captureContent": false,
"lockCaptureContent": true,
"serviceName": "copilot",
"resourceAttributes": {
"deployment.environment": "production"
},
"headers": {
"Authorization": "Bearer <token>"
}
}
}This illustrates the documented configuration model rather than establishing that every field works identically in the GitHub Copilot app. GitHub lists the app among the clients supported by enterprise-managed settings, but also cautions that individual property support varies by client. Administrators should therefore confirm the telemetry properties supported by the app before adopting a complete configuration.
Why this matters for engineering teams
Centralized telemetry can give platform and engineering teams a shared view of Copilot agent activity. Instead of relying on separate monitoring arrangements for individual developers, organizations can direct supported telemetry to an existing observability environment or to a Collector that processes and forwards it.
The available signals may help teams investigate agent sessions, understand model and tool interactions, and analyze token-usage measurements. Events describing user responses to edits can also provide context about how proposed changes are received. The supplied documentation does not define particular performance, sampling, retention, or cost outcomes, so organizations should not assume that the feature provides a specific volume or operational guarantee.
The feature is also relevant to governance. Enterprise-managed settings can be centrally distributed and enforced for supported clients. When a setting is not configured as overridable, users cannot change it. That makes the configuration useful for establishing organization-wide telemetry and content-capture rules, subject to the properties supported by each client.
Content capture requires a separate review
Prompts, responses, and tool arguments are excluded by default. Administrators can optionally enable content capture, but the resulting telemetry may include code, file contents, and user prompts.
That makes captureContent a significant data-handling choice rather than a routine diagnostic switch. Teams should begin with content capture disabled and review their requirements before turning it on. They should also evaluate the security and access controls of the receiving OTLP-compatible backend. The documented configuration includes a Bearer token in the headers object; that is an example of how authorization can be supplied, not evidence that it is the only supported authentication method.
What you should do
- Identify the telemetry destination. Use a monitoring platform that supports OTLP directly, or deploy an OpenTelemetry Collector that can receive, process, and forward the data.
- Review the managed-settings schema. Check the enterprise-managed settings reference for the documented telemetry fields and configuration structure.
- Start without content capture. Keep
captureContentset tofalsewhile evaluating the data produced and the organization’s handling requirements. - Validate client support. The managed-settings guide lists Copilot CLI, VS Code, the GitHub Copilot app, Copilot cloud agent, and JetBrains IDEs as supported clients, but property coverage differs. Confirm that the app supports the fields your deployment needs.
- Protect authorization data. If headers contain credentials, handle the managed-settings file and the receiving system according to your organization’s credential-protection practices.
- Define an analysis process. Decide how teams will use traces, metrics, and events for troubleshooting, session analysis, and usage analysis before enabling organization-wide export.
The managed-settings getting-started guide provides the broader administration context for distributing settings across supported Copilot clients.
Availability and open questions
The capability is announced for the GitHub Copilot app and is configured through enterprise-managed settings. The supplied documentation does not establish regional rollout details, product-version requirements, plan-specific availability, or support across every Copilot app edition.
It also does not document telemetry retention, sampling, batching, retry behavior, performance impact, volume, or cost limits. Those details should be treated as undocumented rather than assumed. Most importantly, the existence of a complete telemetry schema in the managed-settings reference does not prove that every listed sub-property is supported by the GitHub Copilot app.
For administrators, the practical starting point is a controlled deployment with content capture disabled, a confirmed OTLP destination, and client-specific validation before expanding the configuration.
