mirror of
https://github.com/crewAIInc/crewAI.git
synced 2026-08-13 01:38:41 +00:00
8b646620be
* fix(telemetry): stop a failed turn from marking the next one failed
A conversational session that opts out of deferred finalization ends each
turn with its own FlowFailedEvent, emitted inside kickoff() before
handle_turn() emits ConversationTurnFailedEvent. The flag was therefore set
after the run that owned it had already cleared it, survived on the
instance, and reported the next healthy turn as failed.
Gate the flag on the run still having its start stamp: a deferring session
keeps it (no per-turn terminal event), so it still reports a failed turn at
session end.
Also aligns the Flow Lifecycle Signals privacy row with the rest of the
telemetry table, which qualifies every user-authored field it records with
"should not include personal info", and fixes a telemetry test that built
InputResponse with an unsupported `value` keyword - ask() swallowed the
TypeError, so the test asserted the signals while exercising the
provider-error path.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(telemetry): cover the streamed turn emitter of the failure flag
stream_turn() is the second emitter of ConversationTurnFailedEvent and
leaks the same flag as handle_turn(). Both regression tests fail on
77c68bd with ['failed', 'failed'].
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
85 lines
7.5 KiB
Plaintext
85 lines
7.5 KiB
Plaintext
---
|
|
title: Telemetry
|
|
description: Understanding the telemetry data collected by CrewAI and how it contributes to the enhancement of the library.
|
|
icon: signal-stream
|
|
mode: "wide"
|
|
---
|
|
|
|
## Telemetry
|
|
|
|
<Note>
|
|
By default, we collect no data that would be considered personal information under GDPR and other privacy regulations.
|
|
We do collect Tool's names and Agent's roles, so be advised not to include any personal information in the tool's names or the Agent's roles.
|
|
Because no personal information is collected, it's not necessary to worry about data residency.
|
|
When `share_crew` is enabled, additional data is collected which may contain personal information if included by the user.
|
|
Users should exercise caution when enabling this feature to ensure compliance with privacy regulations.
|
|
</Note>
|
|
|
|
CrewAI utilizes anonymous telemetry to gather usage statistics with the primary goal of enhancing the library.
|
|
Our focus is on improving and developing the features, integrations, and tools most utilized by our users.
|
|
|
|
It's pivotal to understand that by default, **NO personal data is collected** concerning prompts, task descriptions, agents' backstories or goals,
|
|
usage of tools, API calls, responses, any data processed by the agents, or secrets and environment variables.
|
|
When the `share_crew` feature is enabled, detailed data including task descriptions, agents' backstories or goals, and other specific attributes are collected
|
|
to provide deeper insights. This expanded data collection may include personal information if users have incorporated it into their crews or tasks.
|
|
Users should carefully consider the content of their crews and tasks before enabling `share_crew`.
|
|
Users can disable telemetry by setting the environment variable `CREWAI_DISABLE_TELEMETRY` to `true` or by setting `OTEL_SDK_DISABLED` to `true` (note that the latter disables all OpenTelemetry instrumentation globally).
|
|
|
|
### Examples:
|
|
```python
|
|
# Disable CrewAI telemetry only
|
|
os.environ['CREWAI_DISABLE_TELEMETRY'] = 'true'
|
|
|
|
# Disable all OpenTelemetry (including CrewAI)
|
|
os.environ['OTEL_SDK_DISABLED'] = 'true'
|
|
```
|
|
|
|
### Isolation from your own OpenTelemetry setup
|
|
|
|
CrewAI's telemetry runs on its own private `TracerProvider` and never registers
|
|
itself as the global one. This keeps the two directions separate:
|
|
|
|
- Spans from other instrumented libraries in your process — web frameworks,
|
|
database clients, HTTP clients — are never sent to CrewAI.
|
|
- CrewAI's telemetry spans are never sent to your observability backend, so they
|
|
will not appear in Langfuse, Braintrust, Phoenix, or any other collector you
|
|
configure.
|
|
|
|
Observability integrations are unaffected: they instrument CrewAI through their
|
|
own tracer provider, which is independent of the one described here.
|
|
|
|
### Data Explanation:
|
|
| Defaulted | Data | Reason and Specifics |
|
|
|:----------|:------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------|
|
|
| Yes | CrewAI and Python Version | Tracks software versions. Example: CrewAI v1.2.3, Python 3.8.10. No personal data. |
|
|
| Yes | Crew Metadata | Includes: randomly generated key and ID, process type (e.g., 'sequential', 'parallel'), boolean flag for memory usage (true/false), count of tasks, count of agents. All non-personal. |
|
|
| Yes | Agent Data | Includes: randomly generated key and ID, role name (should not include personal info), boolean settings (verbose, delegation enabled, code execution allowed), max iterations, max RPM, max retry limit, LLM info (see LLM Attributes), list of tool names (should not include personal info). No personal data. |
|
|
| Yes | Task Metadata | Includes: randomly generated key and ID, boolean execution settings (async_execution, human_input), associated agent's role and key, list of tool names. All non-personal. |
|
|
| Yes | Tool Usage Statistics | Includes: tool name (should not include personal info), number of usage attempts (integer), LLM attributes used. No personal data. |
|
|
| Yes | Test Execution Data | Includes: crew's randomly generated key and ID, number of iterations, model name used, quality score (float), execution time (in seconds). All non-personal. |
|
|
| Yes | Task Lifecycle Data | Includes: creation and execution start/end times, crew and task identifiers. Stored as spans with timestamps. No personal data. |
|
|
| Yes | LLM Attributes | Includes: name, model_name, model, top_k, temperature, and class name of the LLM. All technical, non-personal data. |
|
|
| Yes | Crew Deployment attempt using crewAI CLI | Includes: The fact a deploy is being made and crew id, and if it's trying to pull logs, no other data. |
|
|
| Yes | Execution Environment | Includes: which AI coding assistant is running the process, if any (one of a fixed list such as `claude_code`, `codex`, `cursor`, or `unknown`), where the process runs (one of a fixed list such as `ci`, `container`, `serverless`, `interactive`), and the `project_id` from your `pyproject.toml` when one is configured. Detection reads only whether known environment variables are set, never their values. No personal data. |
|
|
| Yes | Flow Lifecycle Signals | Includes: that a flow started, whether it completed or failed, whether one of its methods failed, whether it paused for human input or feedback, whether the start was a resumed run, whether a conversation turn failed, how long the flow ran, and whether the flow is one CrewAI runs internally or one you wrote. The flow name is recorded (should not include personal info), as it already is for flow creation and execution. Method names, error messages and flow state are never recorded. No personal data. |
|
|
| No | Agent's Expanded Data | Includes: goal description, backstory text, i18n prompt file identifier. Users should ensure no personal info is included in text fields. |
|
|
| No | Detailed Task Information | Includes: task description, expected output description, context references. Users should ensure no personal info is included in these fields. |
|
|
| No | Environment Information | Includes: platform, release, system, version, and CPU count. Example: 'Windows 10', 'x86_64'. No personal data. |
|
|
| No | Crew and Task Inputs and Outputs | Includes: input parameters and output results as non-identifiable data. Users should ensure no personal info is included. |
|
|
| No | Comprehensive Crew Execution Data | Includes: detailed logs of crew operations, all agents and tasks data, final output. All non-personal and technical in nature. |
|
|
|
|
<Note>
|
|
"No" in the "Defaulted" column indicates that this data is only collected when `share_crew` is set to `true`.
|
|
</Note>
|
|
|
|
### Opt-In Further Telemetry Sharing
|
|
|
|
Users can choose to share their complete telemetry data by enabling the `share_crew` attribute to `True` in their crew configurations.
|
|
Enabling `share_crew` results in the collection of detailed crew and task execution data, including `goal`, `backstory`, `context`, and `output` of tasks.
|
|
This enables a deeper insight into usage patterns.
|
|
|
|
<Warning>
|
|
If you enable `share_crew`, the collected data may include personal information if it has been incorporated into crew configurations, task descriptions, or outputs.
|
|
Users should carefully review their data and ensure compliance with GDPR and other applicable privacy regulations before enabling this feature.
|
|
</Warning>
|