Claude Code OpenTelemetry Monitoring: A Practical Guide for Companies

Claude Code OpenTelemetry Monitoring: A Practical Guide for Companies

To set up Claude Code OpenTelemetry monitoring, enable telemetry through environment variables, point the export at a company-controlled OTLP collector, and read two kinds of data: metrics (sessions, tokens, cost, edit decisions) and events (API requests, tool results). A useful dashboard aggregates that data by team and by project, answers management questions, and leaves out prompt content and rankings of individuals.

The starting point is not the dashboard tool. It is a decision about what you need to know and what you do not need to see.

Key takeaways

• Claude Code exports telemetry in the OpenTelemetry standard. It is off by default, and you choose where it goes.
• Metrics are for trends and cost. Events are for investigating behavior, failures and tool use.
• Prompt content should not be exported unless there is an explicit, documented decision to do so.
• Aggregating by team, project and cost center answers most management questions without exposing individuals.
• Start with a small dashboard, review it after a few weeks, and cut anything nobody used to make a decision.

What can Claude Code export?

The official Claude Code documentation describes telemetry as part of its OpenTelemetry support. Exact names change over time, so treat the list below as a map and check the Claude Code monitoring documentation from Anthropic before you write any queries.

Among the metrics, these usually matter for management:

• Session count: shows adoption, meaning how many sessions happen over time.
• Token usage, split by type (input, output, cache) and by model: the basis for understanding consumption. If the concept is new to your team, read what tokens are in AI and why they set the cost.
• Estimated usage cost: useful for trends and comparing periods, not as an invoice. Real billing comes from your contract.
• Lines of code changed, commits and pull requests created with the tool's help: activity indicators, not quality indicators.
• Decisions on code edits (accepted or rejected): they say a lot about trust in the tool and about the quality of its suggestions.
• Active usage time: a rough indicator of engagement.

Among the events, exported as OpenTelemetry logs:

• Requests to the model API, with the model used, duration and token volume.
• API errors, useful for spotting instability, usage limits or misconfiguration.
• Tool results: which tool ran, whether it succeeded and how long it took.
• Permission decisions on tools: whether they were approved, by what mechanism and with what outcome.
• A record that a prompt was submitted. By default the prompt text is omitted, and there is an explicit option to include it.

That last distinction is the center of the ethical and legal discussion. Knowing that a prompt happened and what it cost is operational telemetry. Storing the text means storing what a person thought, asked and pasted, including code snippets, names and possibly personal data.

How to enable telemetry step by step

The path below fits a pilot with one team. The variable names follow the official documentation, so confirm them against the version you run.

• Stand up an OpenTelemetry collector (the OpenTelemetry Collector is the common choice) in an environment the company controls, with authentication on the endpoint.
• Choose where the data will be stored: a metrics backend and a logs backend that your infrastructure team already operates. Do not build a new stack just for this.
• Set the variable that enables Claude Code telemetry (CLAUDE_CODE_ENABLE_TELEMETRY).
• Configure the metrics and logs exporters (OTEL_METRICS_EXPORTER and OTEL_LOGS_EXPORTER) to use OTLP, and set the protocol and collector address (OTEL_EXPORTER_OTLP_PROTOCOL and OTEL_EXPORTER_OTLP_ENDPOINT).
• If the collector requires credentials, pass them through a header (OTEL_EXPORTER_OTLP_HEADERS) sourced from a secrets vault, never written into a repository.
• Tag the data with resource attributes such as team, project or cost center (OTEL_RESOURCE_ATTRIBUTES), so you can aggregate without relying on individual identity.
• Distribute the configuration centrally, through organization-managed settings when your plan allows it, so nobody has to remember to export variables on their own machine.
• Test first with the console exporter on a test machine, to see exactly which fields come out before anything is sent to the collector.

On that last item: looking at the raw data before storing it is the cheapest privacy step there is. If a field surprises you, it is better to find out before it sits in a database with months of retention.

Which questions should the dashboard answer?

A dashboard starts with questions, not with whatever charts are available. These are the ones that usually support real decisions:

• Is adoption growing, flat or falling in each team? This shows where training is missing or where the tool does not fit.
• Are token consumption and estimated cost per project within expectations? This supports the budget conversation.
• What share of suggested edits is accepted? A high rejection rate can point to poor context, weak project instructions or unsuitable tasks.
• Which tools fail most often? Repeated failures usually point to a configuration, permission or integration problem.
• Are API errors concentrated at certain hours or on a certain model? This separates tool problems from network or usage-limit problems.
• Do permission decisions show too much automatic approval on sensitive actions? This ties monitoring to Claude Code security: permissions, sandbox and secrets.

A lean layout fits in three blocks: adoption and cost at the top, interaction quality (edit acceptance, tool failures) in the middle, and operational health (API errors, latency) at the bottom. If a question does not lead to a possible action, the matching chart probably does not need to exist.

How do you keep the dashboard from becoming individual surveillance?

The risk does not come from OpenTelemetry. It comes from configuration and usage choices. A dashboard that shows who used the tool least, who accepted the fewest suggestions or who spent the most tends to produce defensive behavior: people use the tool to look productive, hide doubts or avoid complex tasks because they cost more. That destroys the very data you wanted. The article on how to measure AI productivity without surveillance goes deeper into this reasoning.

A practical decision guide, written as rules:

• Do not export prompt text. Keep the content-logging option off, and treat any exception as a separate project with a purpose, a time limit and an approval.
• Prefer team and project attributes to personal identifiers. When the tool includes an email or account identifier in the data, check whether your backend needs to store it. If not, remove or pseudonymize it in the collector.
• Avoid high-cardinality attributes on metrics, such as session identifiers, unless there is a clear need. Besides storage cost, they make it easier to reconstruct one person's behavior.
• Set a minimum group size for display. If a team has two people, the aggregate is effectively individual.
• Restrict access to the dashboard and to raw logs. Someone who views the trend chart does not need to see the detailed event.
• Set short retention for detailed events and longer retention for aggregates.
• Write down, before switching it on, what the data will be used for and what it will not be used for. For example: never for individual performance evaluation.
• Tell the team what is collected. Transparency reduces distrust and is consistent with the principles of Brazil's LGPD, such as purpose, necessity and transparency.

On LGPD: usage data tied to an identifiable person can be personal data. That does not mean monitoring is forbidden. It means it needs a clear purpose, minimization and controlled access. For official guidance, consult the ANPD (Brazil's data protection authority) and validate the design with your company's legal counsel.

Illustrative scenario: a dashboard for a development team

Imagine a software company with three teams that recently adopted Claude Code. Leadership wants to understand whether it is worth expanding use, but does not want to compare developers. This is an illustrative scenario, not a real case.

The configuration tags each machine with team and project. The collector strips account identifiers before writing anything. Prompt text stays off. The dashboard shows, per team: sessions over the weeks, tokens and estimated cost per project, edit acceptance rate, the tools with the most failures, and API errors.

After a few weeks, the reading shows that one team has many rejected edits and repeated failures from the same tool. The right conclusion is not to chase the team but to investigate: perhaps a project instructions file is missing, or the tool's permission is misconfigured. The action is support and standardization, for example creating Claude Code skills that encode that project's testing standard. Afterward, the dashboard shows whether acceptance improved.

In this scenario, monitoring improved the working environment instead of judging people. That is the quality test for the dashboard: every chart should point to a possible improvement in the process.

Applying the map, limit, pilot and transfer approach

The method we use in AI projects fits well here. Map: list who uses Claude Code, on which projects, and which decisions the monitoring must support, recording where things stand today. Limit: define which fields leave the machine, which stay out, who has access and how long the data is kept. Pilot: turn telemetry on for one team, with logs checked and a success criterion agreed in advance, such as being able to answer three management questions without looking at individual data. Transfer: hand the dashboard, the documentation and the review routine to whoever will operate it, and decide whether to expand, adjust or stop. To structure the pilot criteria, the article on how to measure an AI automation pilot offers metrics and decision gates that apply here too.

Observability basics that help

If your infrastructure team has never worked with OpenTelemetry, the observability primer in the OpenTelemetry project documentation explains the difference between metrics, logs and traces, and why the collector sits between the source and the storage. That intermediary is what lets you filter data, remove attributes and swap backends without touching every developer machine, and it is exactly where you apply the privacy rules described above.

Frequently asked questions

Does Claude Code send telemetry to Anthropic without my configuring it?

The OpenTelemetry telemetry described here is opt-in: you enable it and define the destination. This is different from other operational and error services the tool may have. Check the official documentation and your plan's data policy to see what applies in your case.

Can I see what each developer asked the tool?

Technically there is an option to include prompt text in the events, but it is off by default for a good reason. We recommend keeping it off, because prompts can contain sensitive code, secrets and personal data, and because storing that content changes the nature of the monitoring. If there is a specific need, treat it as an exception with a defined purpose and time limit.

Is the cost shown on the dashboard what I will pay?

Not necessarily. The exported cost is an estimate that is useful for trends and for comparing projects, but billing depends on your contract and how you access the model. Use the dashboard to detect variations and the vendor invoice for the official amount.

Do I need a paid observability tool to start?

No. Because the format is OpenTelemetry, you can use the backend your company already runs, or start with the console exporter to validate the fields. At the beginning, what matters is deciding the questions, the privacy rules and who is responsible for maintaining the dashboard, and only then choosing where to store the data.

Sources

• Anthropic: monitoramento de uso do Claude Code com OpenTelemetry
• OpenTelemetry: conceitos de observabilidade
• ANPD: Autoridade Nacional de Proteção de Dados