Monitoring

Track Cowork usage and activity across your organization by exporting events through OpenTelemetry (OTel). Cowork exports events via the OTel logs/events protocol, giving you visibility into user prompts, model responses, API requests, tool usage, and errors.

​

Setup

Configure monitoring from the Cowork admin settings:

1. Navigate to Admin settings > Cowork
2. Configure the following fields:

   Field	Description	Example
   OTLP endpoint	Your OpenTelemetry collector URL	http://collector.example.com:4318
   OTLP protocol	Transport protocol	http/json or http/protobuf
   OTLP headers	Authentication headers for your collector	Authorization=Bearer your-token

3. Save your settings
4. Start a new Cowork session — settings are loaded at session start, so existing sessions won’t pick up the new configuration

​

Events

Cowork exports the following events to your OTel collector. The collector settings in Setup apply to every Cowork session that runs on a user’s computer in Claude Desktop, including Cowork tasks that Dispatch starts. They don’t apply to Code tab sessions, including Code sessions that Dispatch starts. Whether events include user prompt text, model response text, and tool inputs depends on the otlpContentCapture managed configuration key on each user’s device.

​

Content capture

Events can carry user prompt text, model response text, and tool inputs in addition to metadata. You set which of these the events carry with the otlpContentCapture managed configuration key on each user’s device. To set the key, deploy it with your device management tool to the managed configuration location for each operating system. To export metadata only, set otlpContentCapture to an empty list, written as the two characters []. Claude Desktop reads an empty string as if the key weren’t set. The key takes effect when Claude Desktop restarts. The table shows what events carry on Claude Desktop version 1.17377 or later, for a Cowork session that runs on the user’s computer. Metadata includes workspace.host_paths and, on first-party deployments, user.email. The key doesn’t control either one. See Security and privacy.

​

Event correlation

When a user submits a prompt, Cowork may make multiple API calls and run several tools. The prompt.id attribute links all events back to the single prompt that triggered them. To trace all activity triggered by a single prompt, filter your events by a specific prompt.id value. On third-party deployments, you can additionally enable OpenTelemetry trace export with the otlpTracesEnabled setting (beta). When it is enabled, events emitted while a prompt is processed also carry trace_id and span_id, linking them to the session’s trace spans for end-to-end correlation in your observability backend.

​

Standard attributes

All events include these attributes:

​

User prompt event

Logged when a user submits a prompt. Event name: user_prompt Attributes: All standard attributes, plus:

​

Model response event

Logged when the model completes a response that includes text output. Requires Claude desktop app version 1.17377 or later. Event name: assistant_response Attributes: All standard attributes, plus: Model responses are captured when otlpContentCapture includes assistantResponses, and also whenever user prompts are captured.

​

Tool result event

Logged when a tool completes execution. Event name: tool_result Attributes: All standard attributes, plus:

​

API request event

Logged for each API request to Claude. Event name: api_request Attributes: All standard attributes, plus:

​

API error event

Logged when an API request to Claude fails. Event name: api_error Attributes: All standard attributes, plus:

​

Tool decision event

Logged when a tool permission decision is made. Event name: tool_decision Attributes: All standard attributes, plus:

​

Event analysis

The exported events support a range of analyses: Tool usage patterns — Analyze tool result events to identify most frequently used tools, success rates, average execution times, and error patterns. Cost monitoring — Track cost_usd from API request events to understand usage trends across users and teams. Group by user.account_uuid or organization.id for per-user or per-team breakdowns. Performance monitoring — Track API request durations and tool execution times to identify performance bottlenecks.

​

Backend considerations

Your choice of logs backend determines the types of analyses you can perform:

• Log aggregation systems (e.g., Elasticsearch, Loki): Full-text search and log analysis
• Columnar stores (e.g., ClickHouse): Structured event analysis and complex queries
• Observability platforms (e.g., Honeycomb, Datadog): Advanced querying, visualization, and alerting

​

Service information

All events are exported with the following resource attributes:

​

Security and privacy

• Events are only exported when an admin configures the OTLP endpoint
• The otlpContentCapture key on each device sets which content events carry. Each category you list in the key adds its content. The full category list has two more than these three:
  • userPrompts: user prompt text
  • assistantResponses: model response text
  • toolDetails: the arguments a tool was called with, in tool_input and tool_parameters, such as shell commands, file paths, URLs, and search patterns. It also covers the text of a failed tool’s error message, in error on the tool result event
• On Claude Desktop version 1.17377 or later, events that carry user prompt text also carry model response text, even when the key doesn’t list assistantResponses
• On Claude Desktop version 1.17377 or later, when otlpContentCapture isn’t set on a device in a first-party deployment, events carry user prompt text, model response text, and the toolDetails content. To export metadata only, set the key to an empty list, []
• Metadata includes workspace.host_paths, the paths of the folders a user connects to a task. otlpContentCapture doesn’t control this attribute, so events carry the paths even when the key is []. If folder names can be sensitive, configure your telemetry backend to filter or redact it
• On first-party deployments, user.email is always included in event attributes, so configure your telemetry backend to filter or redact it if this is a concern
• On third-party deployments, user.email is absent; the export identifies users with the enduser.id resource attribute, controlled by the endUserAttribution setting