skip to content

Log Levels and Verbosity Flags

4 roadmaps5 questions

The CLI log levels from quiet through debug, the default lifecycle level, and the stacktrace flags. Asked because picking the right flag is the first step in every build investigation.

on this pageshow

explore

questions

5

Walk me through the CLI flags that change Gradle's log verbosity and what each one does.

level: juniorimportance: must knowfreq 50%

answer

  1. -q quiet, -i info, -d debug
  2. -i = incremental/cache debugging
  3. last flag wins, one level active
  4. stacktrace flags are separate
  5. -d adds timestamps + threads

basics

~10 s

-q/--quiet shows only errors and important messages; -i/--info adds informational detail like up-to-date reasons; -d/--debug shows everything including internals and timestamps. No flag means the default LIFECYCLE level.

solid answer

~40 s

Gradle exposes its log levels through short and long CLI flags. **`-q` / `--quiet`** drops you to QUIET: almost silent, just errors and `println`-style important messages. **`-i` / `--info`** raises to INFO: you see *why* tasks ran or were skipped (UP-TO-DATE, FROM-CACHE), dependency resolution notes, and lifecycle-callback hints — invaluable for diagnosing incremental-build misses. **`-d` / `--debug`** is DEBUG: the firehose — every internal message, full dependency resolution, plus a timestamp and thread on each line. The default (no flag) is LIFECYCLE. Only one level can be active; if you pass several, the **last one wins**. Separately, `-s`/`--stacktrace` and `-S`/`--full-stacktrace` control *exception detail* on failure, not the log level — they are orthogonal and can combine with any verbosity flag.

code

bash · 3 lines
bash
gradle build -i      # INFO: up-to-date reasons, cache hits
gradle build -q      # QUIET: near-silent
gradle build -d      # DEBUG: full firehose with timestamps

go deeper

for a junior

Map each short flag to its level: -q quiet, -i info, -d debug; no flag = LIFECYCLE.

for a middle

Explain that -i is the go-to for debugging incremental builds and cache misses, with concrete examples.

for a senior

Note last-flag-wins, that DEBUG adds timestamps/threads, and that stacktrace flags are orthogonal.

for a principal

Recommend verbosity conventions for local vs CI and caution that DEBUG output volume can affect build/log costs.

## The verbosity flags | Long form | Short | Level | What you get | |-----------|-------|-------|--------------| | `--quiet` | `-q` | QUIET | Errors + important messages only; near-silent. | | (none) | — | LIFECYCLE | Default: task progress + build result. | | `--info` | `-i` | INFO | Why tasks ran/were skipped, cache hits, resolution notes. | | `--debug` | `-d` | DEBUG | Everything, plus timestamps and thread names. | | `--warning-mode` | — | (filters warnings) | Orthogonal control of deprecation/warning display. | ## When to reach for each - **`-q`** — scripting or piping Gradle output where you only care about failures, or to reduce noise in a wrapper script. - **`-i`** — the workhorse for debugging **incremental builds and the build cache**. It prints lines like `Task :compileJava UP-TO-DATE` *with the reason*, and shows input/output change detection. If a task reruns when you expected a cache hit, `-i` (or `--info`) is the first tool. - **`-d`** — last resort for deep diagnosis: plugin internals, classpath issues, full dependency graph resolution. Output is huge; usually you redirect it to a file. ## One level at a time, last wins Gradle resolves to a single active level. `gradle build -i -q` runs at QUIET because `-q` came last. Don't expect flags to combine additively. ## Not a verbosity flag: stacktrace flags `-s`/`--stacktrace` and `-S`/`--full-stacktrace` change how much of an **exception** is printed when the build fails. They are independent of the log level — you can run `gradle build -q -s` to stay quiet but still get a stacktrace on failure. ```bash gradle :app:assemble -i # see why each task is or isn't up-to-date gradle build -d > build.log # capture full debug output to a file ```

  • Which flag is most useful for diagnosing why a task wasn't UP-TO-DATE?
    `-i`/`--info` — it prints the reason a task executed or was skipped, including input/output change detection.
  • Does -d also change exception detail on failure?
    No. Exception detail is controlled by --stacktrace/--full-stacktrace, which are independent of the log level.

saying these in an interview costs you the question

  • Saying flags stack additively — only one level is active and the last flag wins.
  • Confusing -d (debug log level) with -s (stacktrace on exceptions).

context

resolving links…

open as a page

What is Gradle's default log level when you run a build, and what kind of output does it show?

level: juniorimportance: must knowfreq 55%

basics

~10 s

The default level is LIFECYCLE. It shows task execution progress, the BUILD SUCCESSFUL/FAILED line, and user-facing messages — but hides INFO and DEBUG detail to keep output concise.

open as a page

What do --stacktrace (-s) and --full-stacktrace (-S) do, and how do they differ from the log-level flags?

level: middleimportance: must knowfreq 45%

basics

~10 s

On a build failure, -s prints a truncated stacktrace (internal Gradle frames filtered out); -S prints the full, unfiltered stacktrace. They control exception detail only — not the log verbosity level.

open as a page

How does Gradle decide which messages to show for a chosen log level, and what happens to standard out and standard error?

level: middleimportance: should knowfreq 35%

basics

~10 s

A chosen level shows messages at that level and all less-verbose levels below it. Standard out is captured at QUIET and standard error at ERROR, so both stay visible even at the default level.

open as a page

How would you choose Gradle log verbosity and stacktrace settings for a CI pipeline versus local development, and how do you set them without changing every command?

level: seniorimportance: should knowfreq 30%

basics

~20 s

Locally keep the LIFECYCLE default and add -i/-s only when debugging. On CI, default to LIFECYCLE plus --stacktrace so failures are diagnosable, avoid --debug (huge logs), and set it via org.gradle.* or GRADLE_OPTS/args rather than per-command flags.

open as a page