Short answer: there isn’t a single “master switch” to stop Prefect from touching logging, but you can take full control so Prefect adds no handlers and sends nothing to the API. Do one of these: - Provide your own logging dictConfig and point Prefect at it - Create a logging YAML that defines exactly what you want (no Prefect handlers), then set

PREFECT_LOGGING_SETTINGS_PATH

to that file. Also disable API logging. - Example YAML that leaves Prefect with no handlers so your own loggers/handlers are in charge:

version: 1
  disable_existing_loggers: False

  handlers: {}

  loggers:
    prefect:
      level: NOTSET
      handlers: []
      propagate: True
    prefect.flow_runs:
      level: NOTSET
      handlers: []
      propagate: True
    prefect.task_runs:
      level: NOTSET
      handlers: []
      propagate: True

  root:
    level: NOTSET
    handlers: []

- Environment:

PREFECT_LOGGING_SETTINGS_PATH=/path/to/logging.yaml
  PREFECT_LOGGING_TO_API_ENABLED=false
  PREFECT_LOGGING_LOG_PRINTS=false

This ensures Prefect does not attach console/API handlers and does not redirect prints; logs from Prefect (if any) will propagate into whatever handlers you configure. - Programmatic hard-disable of Prefect loggers (optional/extra safety) - If you want to be sure Prefect doesn’t emit through its named loggers, you can disable them at process start:

from prefect.logging.loggers import disable_logger, disable_run_logger

  disable_run_logger()         # stops run logger creation/usage
  disable_logger("prefect")    # disable the 'prefect' logger hierarchy

Use this only if you truly want no Prefect logs at all. Notes - If you run flows via a worker/deployment, set the same env vars on the worker runtime so it inherits your config. - To avoid duplicates, keep

propagate: True

on

prefect

loggers in your YAML and do not attach handlers to them; let your root/app loggers handle output. Reference showing

PREFECT_LOGGING_SETTINGS_PATH

usage in 3.x: Flow gets stuck when sending logs to UI from some libraries (issue shows logging.yml + PREFECT_LOGGING_SETTINGS_PATH) If you can share how you run flows (local script vs deployment/worker) I can tailor the exact env/config placement.

Great question. In Prefect 3.x (and you’re on 3.4.14), there are two sources of the “rich” look: 1) Prefect’s Rich-based console handler used for logging (PrefectConsoleHandler) 2) Rich styling/tracebacks used by the CLI/output streams If you’ve pointed PREFECT_LOGGING_SETTINGS_PATH at your own dictConfig but still see Rich output, you’re likely hitting one of the above. Here are the ways to fully remove it. Option A — Turn off styling via settings (fastest) - Disable Rich styling in Prefect logging: - Set env vars: - PREFECT_LOGGING_COLORS=false - PREFECT_LOGGING_MARKUP=false - If you also use the CLI and see colored CLI output/tracebacks: - PREFECT_CLI_COLORS=false - As a belt-and-suspenders approach, many terminals/libraries respect NO_COLOR: - NO_COLOR=1 Option B — Replace the console handler (dictConfig) Point PREFECT_LOGGING_SETTINGS_PATH to a config that uses the standard logging.StreamHandler and a standard formatter, not PrefectConsoleHandler or PrefectFormatter. For example (YAML):

version: 1
disable_existing_loggers: False

formatters:
  standard:
    format: "%(asctime)s | %(levelname)s | %(name)s - %(message)s"

handlers:
  console:
    class: logging.StreamHandler
    level: INFO
    formatter: standard
    stream: <ext://sys.stdout>

loggers:
  prefect:
    level: INFO
    handlers: [console]
    propagate: False

root:
  level: INFO
  handlers: [console]

Notes: - Make sure you do not reference

prefect.logging.handlers.PrefectConsoleHandler

or

prefect.logging.formatters.PrefectFormatter

in this config. - If anything still sneaks in from other libraries, you can set

disable_existing_loggers: True

and explicitly define only the loggers you want. If you still see “rich” tracebacks specifically (not logs): - That’s usually CLI/console handling rather than Python’s logging. Disabling CLI colors via PREFECT_CLI_COLORS=false typically handles this. - As a last resort in your own Python entrypoint you can restore the default excepthook: -

import sys
    sys.excepthook = sys.__excepthook__

If you can share a quick example line of the “rich error logging” you’re still seeing (colored traceback vs. colored log line), I can tailor the exact knob(s) to turn.