[BUG] How can disable tracing prompt?

[IbrahimCanKALYA]

Description

The tracing prompt is repeatedly appearing during crew execution, adding approximately 20 seconds of overhead to each run. I need to disable tracing entirely but cannot find a way to do so. Steps taken:

Set tracing=False on each crew instance Added CREWAI_TRACING_ENABLED=false to .env file

Expected behavior: Tracing should be completely disabled with no prompts appearing during execution. Actual behavior: The tracing prompt continues to appear regardless of the configuration, causing significant execution delays. Environment:

CrewAI version: 0.193.2 Python version: 3.13.5

Steps to Reproduce

1. Execute Crew
2. Tracing prompt appears

Expected behavior

Disable trace prompting entirely

Screenshots/Code snippets

Operating System

macOS Sonoma

Python Version

3.12

crewAI Version

0.193.2

crewAI Tools Version

0.45.0

Virtual Environment

Venv

Evidence

Possible Solution

.

Additional context

.

[Vidit-Ostwal]

Check this documentation once: https://docs.crewai.com/en/telemetry

# Disable CrewAI telemetry only
os.environ['CREWAI_DISABLE_TELEMETRY'] = 'true'

# Disable all OpenTelemetry (including CrewAI)
os.environ['OTEL_SDK_DISABLED'] = 'true'

[IbrahimCanKALYA]

@Vidit-Ostwal it doesn't works :(

[andreivmaksimov]

The following combination worked for me:

CREWAI_DISABLE_TELEMETRY=true
CREWAI_DISABLE_TRACING=true
CREWAI_TELEMETRY=false
OTEL_SDK_DISABLED=true

[etxaleku]

@andreivmaksimov, what versions are you using? I tried your settings and tracing is still occurring for me.

$ crewai version
crewai version: 1.4.1

$ uv run python -c "import crewai; print(crewai.__version__)"
1.4.1

$ uv run python -c "import crewai_tools; print(crewai_tools.__version__)"
1.4.1

My .env file contains:

CREWAI_DISABLE_TELEMETRY=true
CREWAI_DISABLE_TRACING=true
CREWAI_DISABLE_TRACKING=true
CREWAI_TELEMETRY=false
CREWAI_TESTING=true
CREWAI_TRACING_ENABLED=false
OTEL_SDK_DISABLED=true

But whenever I run my crews they always collect and upload traces.

╭──────────────────────────────────────────────────── Trace Batch Finalization ────────────────────────────────────────────────────╮
│ ✅ Trace batch finalized with session ID: ********-****-****-****-************                                             │
│                                                                                                                                  │
│ 🔗 View here:                                                                                                                    │
│ https://app.crewai.com/crewai_plus/ephemeral_trace_batches/********-****-****-****-************
?access_code=TRACE-**********    │
│ 🔑 Access Code: TRACE-**********                                                                                                 │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
╭──────────────────────────────────────────────────────── Crew Completion ─────────────────────────────────────────────────────────╮
│                                                                                                                                  │
│  Crew Execution Completed                                                                                                        │
│  Name: crew      

which of course requires that execute crewai login and successfully authenticate before running my crews (since they are forcing traces).

[JPBlain]

I am experiencing the same issue with version 1.4.1.

The problem appears to stem from calls to finalize_batch() not being conditioned on is_tracing_enabled() within the TraceCollectionListener class, specifically in the handlers for the following events:

• CrewKickoffCompletedEvent
• CrewKickoffFailedEvent

This behavior is located in /crewai/events/listeners/tracing/trace_listener.py.

I removed the unconditional finalize_batch() calls as a temporary workaround in my case.

[etxaleku]

Thanks @JPBlain, that did it, at least until my next upgrade :) Hopefully it gets fixed permanently by then...

As you suggested I updated my copy of crewai/events/listeners/tracing/trace_listener.py version 1.4.1 to -

   207          @event_bus.on(CrewKickoffCompletedEvent)
   208          def on_crew_completed(source: Any, event: CrewKickoffCompletedEvent) -> None:
   209              self._handle_trace_event("crew_kickoff_completed", source, event)
   210              if self.batch_manager.batch_owner_type == "crew":
   211                  if self.first_time_handler.is_first_time:
   212                      self.first_time_handler.mark_events_collected()
   213                      self.first_time_handler.handle_execution_completion()
   214          #       else:
   215          #           self.batch_manager.finalize_batch()
   216
   217          @event_bus.on(CrewKickoffFailedEvent)
   218          def on_crew_failed(source: Any, event: CrewKickoffFailedEvent) -> None:
   219              self._handle_trace_event("crew_kickoff_failed", source, event)
   220              if self.first_time_handler.is_first_time:
   221                  self.first_time_handler.mark_events_collected()
   222                  self.first_time_handler.handle_execution_completion()
   223          #   else:
   224          #       self.batch_manager.finalize_batch()
   225
   226          @event_bus.on(TaskStartedEvent)
   227          def on_task_started(source: Any, event: TaskStartedEvent) -> None:

commenting out lines 214-215 and 223-224 and (together with CREWAI_TRACING_ENABLED=false in .env) I'm no longer getting any tracing notices and most importantly no trace uploads.

[lzskyline]

I've also noticed this issue. Each time I run the code locally, it uploads data to app.crewai.com, which is a bit concerning.

Here's my current configuration:

return Crew(
    agents=self.agents,  # Automatically created by the @agent decorator
    tasks=self.tasks,  # Automatically created by the @task decorator
    process=Process.sequential,
    verbose=True,
    share_crew=False,
    tracing=False,
)

However, after checking the source code, it seems these parameters (share_crew and tracing) should actually default to False. This is quite confusing.

[lzskyline]

I've delved deeper into this peculiar phenomenon, and through analyzing the crewai source code and examining user data files, I've discovered the following:

• crewai features a special mechanism for its first execution, which automatically enables ephemeral tracing—even if I explicitly set tracing=False`.
• On macOS, the file /Users/lzskyline/Library/Application Support/Project_Name/.crewai_user.json displays "first_execution_done": true, confirming this is the trace link generated after the initial run.
• During the initialization of TraceCollectionListener, the function should_auto_collect_first_time_traces() checks if it’s the first execution. If true, it enables tracing, ignoring my tracing=False setting.

The issue seems clear now! No matter how many times I run crewai run on my Mac, it never properly updates the "first run" flag to False, causing my parameter to fail. I manually modified this value, but it only works once before being overwritten back to True. Configuration via .env environment variables remains unaffected by this parameter:

OTEL_SDK_DISABLED=true
CREWAI_DISABLE_TELEMETRY=true
CREWAI_DISABLE_TRACKING=true
CREWAI_TRACING_ENABLED=false

[slyfox922]

Any update on an actual solution to this? I am also having the same issue, and the .env variables do not mitigate.

[arcanjo96]

I have the same problem. I deployed the Crewai project on ECS via AWS and I'm still experiencing the same problem of waiting 20 seconds during execution.

[etxaleku]

Update - after upgrading to 1.5.0 it looks like CREWAI_TRACING_ENABLED=false is now respected.

HOWEVER - very frequently during a crew run these Tracing Status panels are now displayed -

╭───────────────────────────────────────────────────────── Tracing Status ─────────────────────────────────────────────────────────╮
│                                                                                                                                  │
│  Info: Tracing is disabled.                                                                                                      │
│                                                                                                                                  │
│  To enable tracing, do any one of these:                                                                                         │
│  • Set tracing=True in your Crew/Flow code                                                                                       │
│  • Set CREWAI_TRACING_ENABLED=true in your project's .env file                                                                   │
│  • Run: crewai traces enable                                                                                                     │
│                                                                                                                                  │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

They are annoying as they clutter the output but they can be ignored and don't seem to carry a performance penalty.

[arcanjo96]

@etxaleku Hi, how are you? If I update my project to version 1.5.0, is there a high chance it will break?

dependencies = [
    "crewai[tools]>=0.201.1,<1.0.0",
    "ragas>=0.3.6",
    "redis>=6.4.0",
    "mcp>=1.0.0",
    "crewai-tools[mcp]>=0.75.0",
    "fastmcp>=0.2.0",
    "uvicorn>=0.32.0",
]

[curif]

Same situation for me.

I understand they're trying to build a business around crewai services, but I don't think this is the way to do it.

I'm running it in a container with these env vars:

declare -x CREWAI_DISABLE_TELEMETRY="true"
declare -x CREWAI_DISABLE_TRACKING="true"
declare -x CREWAI_TRACING_ENABLED="false"
declare -x OTEL_SDK_DISABLED="true"

toml file:

dependencies = [
  "crewai-tools[mcp]>=1.5.0",
  "crewai[google-genai,litellm,tools]==1.5.0",
  "fastapi>=0.116.1",
  "mlflow==3.3.2",
  "schedule>=1.2.2",
  "starlette>=0.40.0",
  "uvicorn>=0.35.0",
]

Any clue about how to, at least, avoid the 20s delay? Thanks.

[curif]

CREWAI_TESTING=true as workaround fixed the problem.