skip to content

What is the networkTimeout key in gradle-wrapper.properties, and when would you adjust it?

level: middleimportance: should knowfreq 30%

answer

  1. milliseconds, default 10000
  2. added in Gradle 7.6
  3. only the distribution download
  4. not dependency resolution
  5. irrelevant once cached

basics

~10 s

networkTimeout sets, in milliseconds, how long the wrapper waits when connecting to and reading from the distribution download. It defaults to 10000 (10s). Raise it on slow or high-latency networks/mirrors where downloads time out.

solid answer

~40 s

`networkTimeout` (added in Gradle 7.6) is a wrapper-properties key giving the **timeout in milliseconds** that the wrapper applies when **downloading the Gradle distribution** named by `distributionUrl`. It governs the connect and read timeouts of that single bootstrap download — *not* dependency resolution or any task execution, which have their own settings. The default is `10000` (10 seconds). You raise it when the wrapper aborts mid-download on slow corporate links, throttled internal mirrors, or high-latency CI runners, where a 10-second read timeout is too aggressive for a ~100 MB distribution. It is written automatically by the `wrapper` task (`./gradlew wrapper --network-timeout 60000`). Because it only affects fetching Gradle itself, it has zero impact once the distribution is cached; subsequent builds reuse the cached install and never apply this timeout.

code

bash · 2 lines
bash
# Regenerate wrapper with a longer distribution-download timeout (60s)
./gradlew wrapper --gradle-version 8.7 --network-timeout 60000

go deeper

for a junior

Know it's a millisecond timeout for downloading Gradle, default 10000.

for a middle

Scope it correctly: only the wrapper's distribution download, not dependencies or tasks; raise it for slow networks/mirrors.

for a senior

Explain it's a cold-bootstrap-only knob, irrelevant once cached, and how it interacts with internal mirrors that throttle the distribution.

for a principal

Standardize wrapper timeouts and mirror policy across repos so first-run CI on cold caches doesn't fail org-wide.

## What `networkTimeout` does When you run `./gradlew` and the requested distribution isn't cached yet, the wrapper makes an HTTP(S) request to `distributionUrl` and streams the zip down. `networkTimeout` is the **millisecond timeout** applied to that bootstrap download — covering connection establishment and the read of the stream. It was introduced in **Gradle 7.6**; older properties files simply don't have it and fall back to the built-in default. ```properties distributionUrl=https\://services.gradle.org/distributions/gradle-8.7-bin.zip networkTimeout=10000 ``` The default value is **`10000` (10 seconds)**. ## Scope — what it does NOT cover This is the single most common confusion. `networkTimeout` applies **only to fetching the Gradle distribution via the wrapper**. It does **not** affect: - Dependency downloads from Maven/Ivy repositories (those have their own resolution timeouts / repository config). - Task execution, test timeouts, or the Gradle daemon. - Build cache or toolchain downloads. Once the distribution is already in `~/.gradle/wrapper/dists/`, the wrapper skips the download entirely and `networkTimeout` is irrelevant for that machine. ## When to raise it Typical triggers: - **Slow/high-latency networks** — VPN, geographically distant CI, or constrained bandwidth where a 100 MB `-all` zip can't finish reading in 10s windows. - **Throttled internal mirrors** — many orgs proxy `services.gradle.org` through an artifact repository that streams slowly. - **Flaky CI runners** — first-run cold caches hitting transient slowness. Set it via the `wrapper` task so the jar/scripts stay consistent: ```bash ./gradlew wrapper --gradle-version 8.7 --network-timeout 60000 ``` ## Summary It's a narrow, bootstrap-only knob: a millisecond connect/read timeout for downloading Gradle itself, default 10000, raise it for slow distribution fetches, ignore it everywhere else.

  • Does networkTimeout affect how long Gradle waits to download a dependency from Maven Central?
    No. It only governs downloading the Gradle distribution itself via the wrapper. Dependency resolution has separate timeout/repository settings.
  • After the distribution is cached, does networkTimeout still matter on that machine?
    No. The wrapper skips the download when the distribution is already cached, so the timeout never applies again there.

saying these in an interview costs you the question

  • Claiming networkTimeout controls dependency-download or daemon timeouts.
  • Stating the value is in seconds (it is milliseconds).
  • Assuming every wrapper file has it — it only exists from Gradle 7.6 onward.

context

resolving links…