Troubleshoot AI SDLC Insights

If telemetry is not showing up in Dash0, or you see unexpected data volume or missing metrics, the solutions below address the most common AI SDLC Insights issues. Most problems come down to OpenTelemetry configuration or network connectivity.

No Sessions Appearing

If sessions are not appearing after configuration, work through these checks.

Confirm the endpoint and token. Re-check the otlp_url and auth_token against the values on your agent's integration page under Integrations in Dash0. A common cause is a token that has expired. Check Settings → Auth Tokens and create a new one if needed.

Confirm the time range. Set the time range to cover the session, for example Last 30 minutes. Sessions appear within a minute or two of activity.

For the Claude Code plugin:

1. Verify the plugin is installed: run /plugin and check that dash0 or dash0-agent-plugin appears under Installed.
2. Verify the configuration: /plugin → Installed → dash0 → Configure.
3. Reload plugins after any change: /reload-plugins.
4. Restart the agent. Configuration changes are loaded at startup, so a change made while the agent is running does not take effect until you restart it.

Avoid duplicate installations. If you installed both dash0@claude-plugins-official and dash0-agent-plugin@dash0, uninstall one to avoid duplicate hook firing.

Verify network connectivity. Confirm the machine can reach the Dash0 endpoint. If a request fails, check firewall rules, VPN settings, and proxy configuration.

Claude Desktop Sessions Not Appearing (CLI Works)

If sessions from the Claude Code CLI appear in Dash0 but sessions from the Claude Desktop app do not, the issue is likely how the plugin was configured.

The problem: Configuring via the Plugin UI (/plugin → Configure) writes configuration scoped to the marketplace plugin identity (dash0-agent-plugin@dash0). The CLI uses this identity, so it works. However, Claude Desktop loads its own bundled copy of the plugin under a different identity (@inline). Since userConfig is keyed per plugin identity, the Desktop app runs completely unconfigured: hooks fire and write events locally, but with no OTLP URL the export is a silent no-op. No configuration warnings appear because the Desktop app does not render JSON-formatted system messages from plugin hooks.

The fix: Configure via the .local.md file instead of the Plugin UI. Create ~/.claude/dash0-agent-plugin.local.md with your configuration:

123456789
---
otlp_url: "https://ingress.<region>.aws.dash0.com"
auth_token: "your-dash0-auth-token"
dataset: "default"
agent_name: "claude-code"
team_name: "your-team"
omit_io: true
omit_user_info: false
---

The plugin reads this file on every hook regardless of identity, so it configures both the CLI (@dash0) and Desktop (@inline) variants. After adding the file, restart Claude Desktop. Session start should show dash0: connected and your Desktop sessions will now export.

This is already the primary configuration path in the Claude Code integration. The Plugin UI route only configures the CLI identity and silently leaves Desktop unconfigured.

No Sessions Appearing on Windows

Windows adds a few failure modes of its own.

Claude Code hooks never run. Claude Code runs hook commands through Git Bash on Windows. Install Git for Windows, then restart Claude Code.

Every hook fails with a 404. The plugin is asking a release for a binary it does not carry. Check your architecture with $env:PROCESSOR_ARCHITECTURE, and confirm the release carries assets whose names contain windows.

Cursor or Codex was installed with the shell installer. Both ship a PowerShell installer for Windows. Run install-cursor.ps1 or install-codex.ps1 instead.

Copilot sessions arrive without token usage or tool detail. Copilot was started from cmd.exe, where the launch shell function does not apply. Start it from PowerShell.

For the Windows install steps, open your harness's entry in the Integration Hub.

Everything Is Grouped Under unknown

Telemetry that carries no team attribute is grouped under unknown, which is why an organization that has just started sending data sees most activity there. Set a team on every harness, either as team_name in the harness config file or through the DASH0_TEAM_NAME environment variable, and apply it consistently across developers. See Set Up AI SDLC Insights for details.

Two things make a team name disappear after it was provisioned centrally:

A project-level config file. The project-level and user-level config files do not merge. A repository containing its own .claude/dash0-agent-plugin.local.md hides the user-level file entirely for anyone working in that repository.

A stale assignment. Nothing re-reads team membership on its own. Whichever system writes the file or exports the variable has to run again when someone moves teams.

Missing Token Metrics

If token counts or cache metrics are missing from session details:

Update the agent. Token telemetry requires a recent agent version that follows the GenAI semantic conventions. Check that you are running the latest version.

Inspect span attributes. Use the Trace Explorer to check whether spans include the gen_ai.usage.* attributes:

• gen_ai.usage.input_tokens
• gen_ai.usage.output_tokens
• gen_ai.usage.cache_read.input_tokens
• gen_ai.usage.cache_creation.input_tokens

If these attributes are missing, the agent is not exporting token data.

Check for attribute filtering. Some OpenTelemetry pipelines drop attributes to reduce data size, which can remove token metrics. Make sure your export path preserves them.

Sessions Show as Failed Incorrectly

A session is marked as failed if any of its spans has an error status. This is often correct, because the session did not complete as intended, but it can be surprising when the developer recovered from the error.

Open the session detail panel on the Sessions tab to see which tool calls failed. A single failed tool call, such as a permission-denied file read, marks the whole session as failed. Long-running operations that time out are also marked as failed.

Missing Conversation Content

If the conversation preview on the Sessions tab is empty or incomplete:

Check omit_io. With omit_io set to true, which is the default, prompts and tool input/output are stripped from the telemetry. Set it to false if you want to read full conversations in Dash0, keeping in mind that this sends prompt and tool I/O to your dataset.

Check span event limits. Conversation content is carried as span events. OpenTelemetry has default limits on the number of events per span, so very long sessions can lose events. If you run a custom pipeline, raise the event limit:

1
export OTEL_SPAN_EVENT_COUNT_LIMIT=1000

Duplicate Sessions

If a single invocation produces multiple sessions:

Check for multiple plugin installations. The most common cause is having both plugin versions installed at once. Keep only one of dash0@claude-plugins-official or dash0-agent-plugin@dash0, and uninstall the other with /plugin uninstall <plugin-name>.

Check for a self-install on top of a managed install. After an organization-wide rollout, a developer who had already installed the plugin themselves ends up with both installs enabled, each with its own configuration, and every span is exported twice. Costs and session counts read roughly double. Run claude plugin list, which must show exactly one Dash0 identity with Scope: managed, and uninstall the user-scoped one.

Check for multiple exporters. If you export both directly and through a collector, sessions can be sent twice. Consolidate to a single export path.

A Managed Rollout Produces No Telemetry

If you pushed Claude Code managed settings to the organization and nothing arrives from anyone, work through these in order.

The plugin was configured but never downloaded. This is the most common cause. Managed settings enable and configure a plugin, but they never fetch one, so enabledPlugins names something that was never installed and there is nothing to load. Set the plugin to Required or Installed by default in the claude.ai Organization plugins admin page.

The settings never reached the client. On a developer machine, run /status → Setting sources. It must list Enterprise managed settings. Clients fetch the payload at startup and re-poll hourly, so a developer who has not restarted since the push may still be running without it.

The two managed channels are fighting. Server-managed settings and an on-disk managed-settings.json do not merge. If the console delivers any keys at all, the on-disk file is ignored entirely. Use one channel per organization.

The deployment does not receive server-managed settings. They are not delivered on Bedrock, Vertex, Foundry, or a custom ANTHROPIC_BASE_URL. Use the on-disk file in those environments.

The configuration keys do not match the plugin identity. The keys under pluginConfigs must match the identity in enabledPlugins exactly. A mismatch loads the plugin unconfigured, which exports nothing and warns about nothing.

The machines cannot reach GitHub. The plugin fetches its release binary from github.com on first run. Without that egress it installs but never exports. For container images, pre-bake the plugin cache so nothing is downloaded at runtime.

See Roll Out to Your Whole Organization for the full rollout sequence.

High Data Volume

If an agent generates more telemetry than expected:

Review monitored repositories. Large monorepos and repositories with many files generate more spans per session.

Exclude development sessions. Consider disabling export for local development where observability matters less than performance.

Check for automated processes. Scripts, CI pipelines, or automated tooling can trigger sessions and generate unexpected volume.

Performance Impact

If the agent feels slower after enabling telemetry:

Confirm asynchronous export. Spans should be exported off the main thread so they do not block the session.

Reduce span detail. Keeping omit_io set to true avoids attaching large prompt and tool I/O payloads to spans.

Check network latency. High latency to the Dash0 endpoint slows export. If latency is consistently high, run a local OpenTelemetry Collector as a buffer.

Multi-User Attribution Issues

When you roll AI SDLC Insights out to a team, attribution problems usually come from identity configuration.

Sessions not attributed, or all under one user. The Claude Code plugin reads user.name from each developer's local Git configuration. Confirm each developer has their Git identity set:

1
git config user.name

If you use native Claude Code tracing instead of the plugin, each developer sets their identity through an environment variable:

1
export OTEL_RESOURCE_ATTRIBUTES="user.name=$(git config user.name)"

This value is per developer and cannot be shared, so verify each machine sets its own.

User names appear anonymized. If names show as hashes, omit_user_info is enabled. Set it to false in the plugin configuration and run /reload-plugins to capture readable names.

Inspect What the Agent Sends

To see exactly what the Claude Code plugin exports, run it with debug output enabled:

1
DASH0_DEBUG=true DASH0_DEBUG_FILE=/tmp/dash0-debug.log claude

You can also set DASH0_DEBUG in the plugin configuration through /plugin, then run /reload-plugins. The debug log shows the OpenTelemetry payloads being exported, which is the fastest way to tell whether the problem is data generation or data export.

If telemetry is being generated but sessions still do not appear, the issue is on the export side: re-check the endpoint, the token, and that the export protocol matches the OTLP endpoint shown on your integration page.

Further Reading

• Key Concepts: Understand the data model and terminology.
• Set Up AI SDLC Insights: Configuration, verification, and team attribution.