Warnings

Use the --warn-error flag to promote all warnings to errors or --warn-error-options for granular control through options.

Use --warn-error to promote all warnings to errors

Enabling WARN_ERROR config or setting the --warn-error flag will convert all dbt warnings into errors. Any time dbt would normally warn, it will instead raise an error. Examples include --select criteria that selects no resources, deprecations, configurations with no associated models, invalid test configurations, or tests and freshness checks that are configured to return warnings.

Usage

dbt run --warn-error

Report incorrect code

Proceed with caution in production environments

Using the --warn-error flag or --warn-error-options '{"error": "all"}' will treat all current and future warnings as errors.

This means that if a new warning is introduced in a future version of dbt, your production job may start failing unexpectedly. We recommend proceeding with caution when doing this in production environments, and explicitly listing only the warnings you want to treat as errors in production.

Use --warn-error-options for targeted warnings

In some cases, you may want to convert all warnings to errors. However, when you want some warnings to stay as warnings and only promote or silence specific warnings you can instead use --warn-error-options. The WARN_ERROR_OPTIONS config or --warn-error-options flag gives you more granular control over exactly which types of warnings are treated as errors.

WARN_ERROR and WARN_ERROR_OPTIONS are mutually exclusive

WARN_ERROR and WARN_ERROR_OPTIONS are mutually exclusive. You can only specify one, even when you're specifying the config in multiple places (like env var or a flag), otherwise, you'll see a usage error.

Warnings that should be treated as errors can be specified through the error parameter. Warning names can be found in:

• The types.py file in dbt-labs/dbt, where each class name that inherits from WarnLevel corresponds to a warning name (e.g. AdapterDeprecationWarning, NoNodesForSelectionCriteria).
• Using the --log-format json flag.

(Applies to dbt v1.12 and later)

Starting in v1.12, dbt v1 ignores dbt v2-specific names in warn_error_options (for example, StaticAnalysis and PackageParsingCompatibility) instead of raising an error, and emits a note: <name> is not being used because it's specific to the dbt Fusion engine. This lets you share warn_error_options configs across dbt v1 and dbt v2. Genuine typos still raise an error.

(Applies to dbt v2.0 and later)

In dbt v2, every warning has both a numeric code (for example, 1092) and an event name (for example, NoNodesForSelectionCriteria).

Runtime messages show both, but warn_error_options only accepts the name. Use the event name, v2-native name, or a supported group (all, *). Numeric codes aren't accepted and will cause an error.

To find the name for a code you see in your logs, check out Supported legacy dbt-Core event name aliases.

The error parameter can be set to "all" or "*" to treat all warnings as errors (this behavior is the same as using the --warn-error flag), or to a list of specific warning names to treat as exceptions.

• When error is set to "all" or "*", the optional warn parameter can be set to exclude specific warnings from being treated as exceptions.
• Use the silence parameter to ignore warnings. To silence certain warnings you want to ignore, you can specify them in the silence parameter. This is useful in large projects where certain warnings aren't critical and can be ignored to keep the noise low and logs clean.

Here's how you can use the --warn-error-options flag to promote specific warnings to errors:

• Test warnings with the --warn-error-options '{"error": ["LogTestResult"]}' flag.
• Jinja exception warnings with --warn-error-options '{"error": ["JinjaLogWarning"]}'.
• No nodes selected with --warn-error-options '{"error": ["NoNodesForSelectionCriteria"]}'.
• Deprecation warnings with --warn-error-options '{"error": ["Deprecations"]}' (new in v1.10).

Configuration

You can configure warnings as errors or which warnings to silence, by warn error options through command flag, environment variable, or dbt_project.yml.

You can choose to:

• Promote all warnings to errors using {"error": "all"} or --warn-error flag.
• Promote specific warnings to errors using error and optionally exclude others from being treated as errors with --warn-error-options flag. warn tells dbt to continue treating the warnings as warnings.
• Ignore warnings using silence with --warn-error-options flag.

In the following example, we're silencing the NoNodesForSelectionCriteria warning in the dbt_project.yml file by adding it to the silence parameter:

dbt_project.yml

...
flags:
  warn_error_options:
    error: # Previously called "include"
    warn: # Previously called "exclude"
    silence: # To silence or ignore warnings
      - NoNodesForSelectionCriteria

Report incorrect code

Examples

Here are some examples that show you how to configure warn_error_options using flags or file-based configuration.

Target specific warnings

Some of the examples use NoNodesForSelectionCriteria, which is a specific warning that occurs when your --select flag doesn't match any nodes/resources in your dbt project:

• This command promotes all warnings to errors, except for NoNodesForSelectionCriteria:

  dbt run --warn-error-options '{"error": "all", "warn": ["NoNodesForSelectionCriteria"]}'

  Report incorrect code

• This command promotes all warnings to errors, except for deprecation warnings:

  dbt run --warn-error-options '{"error": "all", "warn": ["Deprecations"]}'

  Report incorrect code

• This command promotes only NoNodesForSelectionCriteria as an error:

  dbt run --warn-error-options '{"error": ["NoNodesForSelectionCriteria"]}'

  Report incorrect code

• This promotes only NoNodesForSelectionCriteria as an error, using an environment variable:

  (Applies to dbt v1.11 and later)

  DBT_ENGINE_WARN_ERROR_OPTIONS='{"error": ["NoNodesForSelectionCriteria"]}' dbt run

  Report incorrect code

Values for error, warn, and/or silence should be passed on as arrays. For example, dbt run --warn-error-options '{"error": "all", "warn": ["NoNodesForSelectionCriteria"]}' not dbt run --warn-error-options '{"error": "all", "warn": "NoNodesForSelectionCriteria"}'.

The following example shows how to promote all warnings to errors, except for the NoNodesForSelectionCriteria warning using the silence and warn parameters in the dbt_project.yml file:

dbt_project.yml

...
flags:
  warn_error_options:
    error: all # Previously called "include"
    warn:      # Previously called "exclude"
      - NoNodesForSelectionCriteria
    silence:   # To silence or ignore warnings
      - NoNodesForSelectionCriteria

Report incorrect code

Promote all warnings to errors

Some examples of how to promote all warnings to errors:

using dbt command flags

dbt run --warn-error
dbt run --warn-error-options '{"error": "all"}'
dbt run --warn-error-options '{"error": "*"}'

Report incorrect code

using environment variables

(Applies to dbt v1.11 and later)

WARN_ERROR=true dbt run 
DBT_ENGINE_WARN_ERROR_OPTIONS='{"error": "all"}' dbt run 
DBT_ENGINE_WARN_ERROR_OPTIONS='{"error": "*"}' dbt run 

Report incorrect code

caution

Note, using warn_error_options: error: "all" will treat all current and future warnings as errors.

This means that if a new warning is introduced in a future version of dbt, your production job may start failing unexpectedly. We recommend proceeding with caution when doing this in production environments, and explicitly listing only the warnings you want to treat as errors in production.

(Applies to dbt v2.0 and later)

dbt v2 behavior and warning codes

dbt v2 fully supports warn_error_options. This section describes important differences from dbt v1 behavior.

Existing dbt-core event names fall into three categories:

• Supported Mapped to similar dbt v2 warning and behave approximately the same.
• Won't be supported: Those that we deliberately decided to not ever support.
• Not supported yet: Parsed, but do nothing yet.

Warning codes in dbt v2

In dbt v2, every warning has both a numeric code (for example, 1092) and an event name (for example, NoNodesForSelectionCriteria). Warning messages at runtime show both, but warn_error_options only accepts the name, never the code:

flags:
  warn_error_options:
    error:
      - NothingToDo   # by name
    silence:
      - FreshnessConfigProblem   # by name

Report incorrect code

Any value that isn't a supported legacy event name, v2-native name, or supported group (all, *) causes dbt v2 to exit with an error at startup, including numeric codes. For example, {error: [1092]} fails, but {error: [NoNodesForSelectionCriteria]} works.

Not every valid name appears in the tables on this page. dbt v2 also emits its own warnings (for example, SemanticModelDeprecated, code dbt1157) that aren't listed here. Use the name shown in the runtime message.

Supported legacy dbt-core event name aliases

When you see a warning code in your logs, use the following table to find the matching event name to put in warn_error_options. The code column is only for looking up warnings you see at runtime — you can't use the code itself in your config:

dbt v2 code (runtime only)	dbt-core event name (use this in config)	Description
1601	NoNodesSelected	No nodes selected
1601	NothingToDo	No nodes selected (alias)
1087	NodeNotFoundOrDisabled	A test or exposure dependency references a missing or disabled node
1085	DeprecatedModel	A model has passed its deprecation date and should be removed
1072	DeprecatedReference	A reference to a model that has already been deprecated
1073	UpcomingReferenceDeprecation	A reference to a model that will be deprecated on a future date
1074	JinjaLogWarning	Jinja exceptions.warn() called in a macro
1075	SnapshotTimestampWarning	Snapshot timestamp column type mismatch
1076	PackageRedirectDeprecation	A package has been redirected to a new name; update your packages.yml
1077	DepsUnpinned	A git-sourced package uses an unpinned revision (HEAD, main, or master)
1078	FreshnessConfigProblem	A source has no freshness configuration; freshness check was skipped
1084	WarnStateTargetEqual	The --state and --target directories are the same path
1086	WEOIncludeExcludeDeprecation	Deprecated include/exclude keys were used in warn_error_options; use error/warn instead
1089	NoNodeForYamlKey	A YAML key references a node that doesn't exist in the project
1090	MacroNotFoundForPatch	A patches: entry in a YAML file references a macro that doesn't exist
1091	InvalidConcurrentBatchesConfig	concurrent_batches is configured but not supported for this model
1092	NoNodesForSelectionCriteria	--select criteria matched no nodes
1093	MicrobatchModelNoEventTimeInputs	A microbatch model has no upstream inputs with event_time configured
1094	UnversionedBreakingChange	A breaking change was made to an unversioned model
1095	UnsupportedConstraintMaterialization	A constraint was defined on a materialization that doesn't support it
1097	UnusedResourceConfigPath	A +config path in dbt_project.yml doesn't match any resources
1098	DepsScrubbedPackageName	A package name contained characters that were scrubbed during install
1099	DepsFoundDuplicatePackage	The same package was found more than once in packages.yml
1506	InvalidMacroAnnotation	A macro's YAML annotation (argument name or type) doesn't match its Jinja definition
no code	LogTestResult	A data test result (pass/warn/fail)
no code	RunResultWarning	A model or test run completed with warn status
no code	RunResultWarningMessage	The message accompanying a warn-status run result

Unsupported dbt v1 event names

Only the legacy names in Supported legacy dbt-Core event name aliases are valid string aliases in dbt v2. There are many other dbt v1 warning event names; if you put one of those in warn_error_options, dbt v2 will throw a warning at startup.

The table below is not a complete list of unsupported names. It only includes dbt v1 event names that dbt v2 recognizes by name so it can emit a startup warning explaining why the entry has no effect and prompting you to remove it: the underlying dbt v1 behavior was removed, replaced, or made unconditional in dbt v2. Many other unsupported dbt v1 names are not listed here; they still warn during startup validation when used in warn_error_options.

dbt-core event name	Message
MicrobatchMacroOutsideOfBatchesDeprecation	dbt v2 only supports the newer behavior-change flag, where this case is a hard error.
SeedExceedsLimitSamePath	This warning comes from partial parsing in dbt v1, which dbt v2 does not support.
SeedIncreased	This warning comes from partial parsing in dbt v1, which dbt v2 does not support.
GenerateSchemaNameNullValueDeprecation	dbt v2 only supports the newer behavior-change flag, where this case is a hard error.
GenericSemanticLayerDeprecation	dbt v2 already implements the new semantic layer spec, so this legacy warning no longer applies.
MFCumulativeTypeParamsDeprecation	dbt v2 already implements the new semantic layer spec, so this legacy warning no longer applies.
MFTimespineWithoutYamlConfigurationDeprecation	dbt v2 already implements the new semantic layer spec, so this legacy warning no longer applies.
MetricAttributesRenamed	dbt v2 already implements the new semantic layer spec, so this legacy warning no longer applies.
TimeDimensionsRequireGranularityDeprecation	dbt v2 already implements the new semantic layer spec, so this legacy warning no longer applies.
SourceFreshnessProjectHooksNotRun	dbt v2 already uses the newer source freshness behavior, so this legacy warning does not apply.
SemanticValidationFailure	dbt v2 does not support semantic models, so this warning does not apply.
ValidationWarning	dbt v2 already validates allowed YAML keys strictly, so this warning would be redundant.
PackageMaterializationOverrideDeprecation	dbt v2 already enforces the latest behavior, which prevents packages from overriding built-in materializations.
TestsConfigDeprecation	dbt v2 does not surface this warning by default, which matches current dbt v1 behavior.
ProjectFlagsMovedDeprecation	dbt v2 already errors on this configuration, which matches newer dbt v1 behavior.
ConfigSourcePathDeprecation	This is now fully deprecated in dbt v2.
ConfigLogPathDeprecation	This is now fully deprecated in dbt v2.
ConfigTargetPathDeprecation	This is now fully deprecated in dbt v2.
ConfigDataPathDeprecation	This is now fully deprecated in dbt v2.
EnvironmentVariableNamespaceDeprecation	dbt v2 reserves the DBT_ENGINE_ prefix and rejects unknown environment variables that use it.
UnusedTables	dbt v2 does not allow source overrides, so packages must disable a source explicitly instead.
WrongResourceSchemaFile	dbt v2 reports this case under NoNodeForYamlKey instead.
PackageNodeDependsOnRootProjectNode	dbt v2 only supports the newer behavior-change flag require_ref_searches_node_package_before_root, where this case is a hard error.

Warnings that are hard errors in dbt v2

Some dbt v1 warning names correspond to behaviors that dbt v2 enforces unconditionally as parse errors. If you reference these names in warn_error_options, dbt v2 emits a startup warning explaining that the entry has no effect. You can carry over your warn_error_options config from dbt v1 without breaking, but these configs do nothing (They will throw a warning as unsupported and should be removed from the config):

dbt-Core event name	dbt v2 behavior	dbt v2 error code
DuplicateYAMLKeysDeprecation	dbt v2's YAML parser rejects duplicate keys as hard parse errors	DuplicateConfigKey (1059)
CustomKeyInConfigDeprecation	Unknown config keys are rejected via strict schema validation	UnusedConfigKey (1060)
CustomTopLevelKeyDeprecation	Unknown top-level schema keys are hard parse errors	UnusedConfigKey (1060)
ResourceNamesWithSpacesDeprecation	Resource names with spaces are rejected during name validation	SchemaError
InvalidValueForField	Field value failures are surfaced as hard parse errors via deserialization	SerializationError
GenericJSONSchemaValidationDeprecation	JSON schema validation failures are hard parse errors	SerializationError
DuplicateNameDistinctNodeTypesDeprecation	Caught as a hard error during node resolution	SchemaError

Enabling --warn-error with static analysis in baseline mode

If your project emits static analysis warnings and you use --warn-error (which promotes all warnings to errors), your project may fail unexpectedly. We recommend explicitly listing the warning categories you want to enforce rather than using error: all when baseline mode is active.

Deprecated include and exclude keys

The legacy include and exclude fields for warn_error_options were deprecated in dbt v1.8 but are still supported in dbt v2. If you use them, dbt v2 emits a WEOIncludeExcludeDeprecation warning (code 1086) and ignores the deprecated keys. Migrate to error, warn, and silence instead:

# Before (dbt ≤1.7)
flags:
  warn_error_options:
    include: all
    exclude:
      - NoNodesForSelectionCriteria

# After (dbt ≥1.8 and v2)
flags:
  warn_error_options:
    error: all
    warn:
      - NoNodesForSelectionCriteria

Report incorrect code

Was this page helpful?

Privacy policyCreate a GitHub issue

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.