Can Claude Code Observe Its Own Code?

One of the great things about OpenTelemetry is that it’s a standard, and standards tend to proliferate. I was excited to see Claude Code add OpenTelemetry metric and log support in a recent release. What was really interesting—beyond the ability to capture usage data from Claude Code—is that you can also get pretty detailed logs about what you’re doing with Claude Code. For instance, how many tokens are being used for each model, which tools are being called, and the length of your sessions.

I plugged in some environment variables (which I’ll talk about in more detail later), started up a new Claude Code session, and saw all of this data pop into my Honeycomb team. That’s when I got to thinking…

Wait, can I get Claude Code to write a dashboard to observe itself?

Spoiler: the answer is yes. 

We’ve been chipping away at our Honeycomb MCP server, and I realized I had a perfect opportunity to try it out. I pointed Claude Code at the environment that its telemetry was being sent to, and told Claude to analyze the telemetry in order to create a board template. For those that don’t know, board templates are a collection of preset queries that we provide for everything from Kubernetes to Redis and everything in between.

I asked Claude to look at how these templates are created and it merrily scurried off to look at the code. Right now, these templates are written in Go and live in our monorepo. After a few moments, Claude had made a plan on how to create new templates. I told Claude to query Honeycomb for the telemetry data that it had been sending, get an understanding of it, and then make a new board template based off of what it found.

It felt very much like a dashboard turducken, but Claude chugged along for a few minutes before spitting out a nearly perfect board template. There were only a handful of changes I had to make manually; it actually nailed all of the important queries out of the box. A quick PR and review later, the new template was rolling out to production.

How do I monitor Claude Code in Honeycomb?

Setting up Claude Code to be monitored in Honeycomb is a straightforward task. First, I suggest you create a new environment for Claude so you’re not mixing the usage data with other stuff. Once you’ve done that, create an ingest key and save it. 

Now, you’ll need to set some environment variables:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER="otlp"
export OTEL_LOGS_EXPORTER="otlp"
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT="api.honeycomb.io:443"
export OTEL_EXPORTER_OTLP_HEADERS=x-honeycomb-team=<ingest key>,x-honeycomb-dataset=claude_metrics
export OTEL_LOG_USER_PROMPTS=1

A quick note: use the correct endpoint for your Honeycomb region and make sure your ingest key can create new datasets. If you’re rolling this out to a team, I suggest you add these environment variables to your developer setup scripts so that everyone has them.

Once you’ve done this, fire up Claude Code. As you use it, you’ll see logs and metrics appear in your new environment in the ‘claude-code’ dataset. To create the monitoring board, go to the ‘Boards’ tab, select ‘Templates,’ and select ‘Claude Code Monitoring.’ You’ll see something like the following screenshot:

Select ‘Use Template’ and you’re off!

Some interesting things to keep an eye on:

• Want to know what your team is using in terms of MCP? Check the ‘Tool Success Rate’ query; it’ll show you not just successful and failed built-in tool calls, but also third-party calls through MCP servers.
• ‘Top Sessions by Activity’ will show you who’s using a lot of Claude Code and let you look into any particularly interesting sessions.
• You can even use BubbleUp Anomaly Detection to look at interesting outliers on API response time!