skip to content

Which command-line flags control Gradle's log verbosity, and how do they relate to one another?

level: juniorimportance: must knowfreq 70%

answer

  1. six ordered levels
  2. LIFECYCLE is default
  3. -i for up-to-date reasons
  4. -d = firehose
  5. -q suppresses

basics

~10 s

Use --quiet (-q) for less output, --info (-i) for more, and --debug (-d) for everything. They set the log level; only one applies, with --debug the most verbose and --quiet the least.

solid answer

~40 s

Gradle has ordered log levels: ERROR, QUIET, WARNING, LIFECYCLE (the default), INFO, DEBUG. The CLI flags shift the threshold: `-q/--quiet` shows only QUIET and ERROR; `-i/--info` adds INFO (task inputs/outputs, up-to-date reasons, why a task ran); `-d/--debug` shows everything including internal Gradle logging and is extremely noisy. There's also `-w/--warn` to surface WARNING and above. You pass one of these; if you pass several the most verbose generally wins, but you should pass just one. `--info` is the everyday diagnostic flag — it explains incremental-build decisions without the firehose of `--debug`. `--debug` also leaks more detail and should be avoided in shared CI logs.

code

bash · 11 lines
bash
# Default lifecycle output
./gradlew test

# INFO: explains up-to-date / cache decisions
./gradlew test --info

# DEBUG: everything including Gradle internals
./gradlew test --debug

# QUIET: only QUIET + ERROR
./gradlew test --quiet

go deeper

for a junior

Name -q/-i/-d and that -i shows more, -d shows everything; that's enough.

for a middle

List the ordered levels, state LIFECYCLE is default, and explain what --info concretely adds (up-to-date reasons, cache notes).

for a senior

Distinguish threshold flags from rendering (--console) and warnings (--warning-mode); recommend --info as the default diagnostic and explain why --debug is a last resort.

for a principal

Advise team conventions: standardize on --info for CI diagnostics with build scans for deeper analysis; avoid --debug artifacts in shared pipelines for log hygiene and to limit leaking internal detail.

## Gradle's log levels Gradle defines six log levels, from least to most verbose: 1. **ERROR** — error messages 2. **QUIET** — important, terse output 3. **WARNING** — warnings 4. **LIFECYCLE** — progress, task names as they run (**the default**) 5. **INFO** — informational: task input/output snapshots, up-to-date checks, dependency resolution notes 6. **DEBUG** — everything, including Gradle's own internal logging The console shows messages **at or above** the selected threshold. By default that threshold is LIFECYCLE. ## The CLI flags | Flag | Short | Threshold becomes | |------|-------|-------------------| | `--quiet` | `-q` | QUIET (suppresses lifecycle/warnings) | | `--warn` | `-w` | WARNING | | (none) | | LIFECYCLE (default) | | `--info` | `-i` | INFO | | `--debug` | `-d` | DEBUG | These are mutually exclusive in intent — pick the one matching how much you want to see. `--info` is the workhorse for diagnosing *why* a build did what it did: it prints up-to-date reasons ("Task ':compileJava' is not up-to-date because..."), cache hit/miss notes, and resolved dependency choices. `--debug` is rarely useful day-to-day; it floods the log and can expose internal paths, so it's discouraged in CI artifacts. ## Where it sits relative to other knobs The flags only set the **threshold**. Separate concerns own *how* output is rendered (`--console=plain|rich|auto`) and *which deprecation warnings* surface (`--warning-mode`); those are reference topics of their own. As a diagnostic CLI tool, you reach for `--info` first, then escalate to `--debug` only when `--info` doesn't reveal the cause. ```bash # Everyday: see why tasks ran / were skipped ./gradlew build --info # Last resort: full firehose ./gradlew build --debug ```

  • What does --info show that the default LIFECYCLE level does not?
    INFO adds task input/output snapshots, up-to-date check reasons, build-cache hit/miss notes, and dependency-resolution detail — the information you need to explain why a task ran or was skipped.
  • Why avoid --debug in CI logs?
    It's extremely verbose (including Gradle internals), bloats logs, slows them down to read, and can surface internal paths/details — reach for --info first and only escalate when needed.

saying these in an interview costs you the question

  • Claiming --info and --debug can be combined for 'extra' detail — you pick one threshold.
  • Saying the default level is INFO (it's LIFECYCLE).
  • Confusing --quiet with silencing errors — ERROR still shows.

context

resolving links…