In Selenium, what does driver.manage().timeouts().implicitlyWait(Duration) change, and what is its default?

juniornice to knowfreq 52%

answer

one number handed to the driver
it decides when a search gives up
a fresh session does not retry at all
the default is zero milliseconds
location only, never element state

basics

~10 s

It sets how long the browser driver keeps retrying an element search before giving up, for every search in that session. The default is zero, so an unmatched locator fails immediately.

solid answer

~30 s

driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)) tells the remote end to keep re-running an element search for up to ten seconds instead of failing on the first miss. In Selenium 4 it takes a java.time.Duration; Python spells the same thing driver.implicitly_wait(10) in seconds, and .NET assigns a TimeSpan to driver.Manage().Timeouts().ImplicitWait. The default is zero, so a fresh session raises NoSuchElementException the instant nothing matches. It is one number of session-wide state: a single call affects every later findElement and findElements on that driver, and getImplicitWaitTimeout() reads it back. It covers element location and nothing else — not visibility, not enabled state, not page loads.

`driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10))` tells the remote end to keep re-running an element search for up to ten seconds instead of failing on the first miss. In Selenium 4 it takes a `java.time.Duration`; Python spells the same thing `driver.implicitly_wait(10)` in seconds, and .NET assigns a `TimeSpan` to `driver.Manage().Timeouts().ImplicitWait`. The default is zero, so a fresh session raises `NoSuchElementException` the instant nothing matches. It is one number of session-wide state: a single call affects every later `findElement` and `findElements` on that driver, and `getImplicitWaitTimeout()` reads it back. It covers element location and nothing else — not visibility, not enabled state, not page loads.

code

java · 20 lines

java

import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

public class BerthGridImplicitWait {

  public static void main(String[] args) {
    WebDriver driver = new ChromeDriver();
    try {
      driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
      System.out.println(driver.manage().timeouts().getImplicitWaitTimeout());

      driver.get("https://marina.example.com/berths");
      driver.findElement(By.cssSelector("#berth-grid tr[data-berth='A17'] .assign")).click();
    } finally {
      driver.quit();
    }
  }
}

go deeper

for a junior

Be ready to write the call from memory and say the default is zero. Knowing that a fresh session fails fast on a missing element is the fact most candidates get wrong at this stage.

for a middle

Explain that the retry loop lives in the driver, not your code, and that the setting is session state rather than a per-call argument. Name the Python and .NET spellings too.

for a senior

Show that you check what a shared harness already set before adding your own value, and that you can say precisely which commands the setting reaches and which it silently does not.

for a principal

Own the position on whether a global implicit wait belongs in the harness at all, given that it changes the timing of every search in code other teams wrote and cannot be scoped to one call site.

What the call actually sets

driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)) writes one number into the browser session's timeouts configuration — the field the WebDriver specification calls the implicit wait timeout. It is not a sleep, and it is not a loop living in your test code. It is a parameter handed to the driver process behind the session (chromedriver, geckodriver, or the driver on the node your Selenium Grid routed you to), which then consults it every time your test asks it to locate an element.

The routine the remote end runs for a search looks like this:

Start a timer set to the implicit wait timeout.
Run the locator against the document and collect everything that matches.
If the collection is still empty and the timer has not fired, run the locator again.
Stop as soon as the collection is non-empty, or when the timer fires.

That is the entire mechanism. Nothing in it inspects the elements it found, so an implicit wait can only ever answer the question "does anything match this locator yet?".

The default is zero

A brand-new session starts with the implicit wait timeout set to 0 milliseconds. With zero, step 3 above never runs: the locator is evaluated once, and if nothing matches, findElement comes back as a no such element error, which the Java client raises as NoSuchElementException. So the out-of-the-box behaviour is fail-fast, and every retry you see in a Selenium suite is something somebody configured on purpose.

Two consequences follow from "one number, session-wide":

It is sticky. One call near session setup changes every later findElement and findElements on that driver, including searches inside page objects and helper code you did not write.
It is readable. driver.manage().timeouts().getImplicitWaitTimeout() returns the current Duration, which is how you check what a shared harness has already done to your session.
It is validated. A negative value, or one past the maximum safe integer, is rejected by the driver as an invalid argument rather than silently clamped.

The same knob in the other bindings

The wire command is identical in every language; only the spelling and the unit differ.

Binding	How you set it	What you pass
Java	`driver.manage().timeouts().implicitlyWait(...)`	a `java.time.Duration`
Python	`driver.implicitly_wait(10)`	seconds, as a number
.NET	`driver.Manage().Timeouts().ImplicitWait = ...`	a `TimeSpan`

The Python spelling is the one that trips people up: implicitly_wait takes seconds, and it is the client that multiplies by a thousand before sending implicit to the driver. Selenium 4 removed the old Java implicitlyWait(long, TimeUnit) overload, so if you find that two-argument form in a codebase you are looking at Selenium 3 code that will not compile against a current client.

Setting it before the first command

You do not have to wait until the session exists. Every Selenium 4 browser options object inherits setImplicitWaitTimeout(Duration), which puts the value into the timeouts capability requested when the session is created:

java

ChromeOptions options = new ChromeOptions();
options.setImplicitWaitTimeout(Duration.ofSeconds(5));

That matters because it means the setting can arrive from somewhere other than the obvious manage().timeouts() line — a capability block in a config file counts too, and an absent implicitlyWait call is therefore not proof that the session is running with zero.

What it does not cover

Reading the marina berth allocation grid makes the boundary concrete. Suppose the page lists berths A1 to A40 with a status cell and an Assign button per row, and the grid is drawn by a script after the page's own load completes.

With an implicit wait set, driver.findElement(By.cssSelector("#berth-grid tr[data-berth='A17']")) keeps retrying while the grid renders, and succeeds once that row exists.
The moment the row exists, the wait is over. If the status cell still reads a dash because a second request has not returned, getText() gives you the dash; the implicit wait does not retry it.
If the Assign button is present but disabled while the berth is still being priced, the click throws ElementNotInteractableException immediately. Presence was satisfied, so nothing retries.
If the grid re-renders between the find and the click, the element reference you hold is stale and the click throws StaleElementReferenceException — again with no retry.

The one-line version for an interview: an implicit wait retries the search, never the result. Everything a real page makes you wait for beyond mere presence — visible, populated, enabled, settled — is somebody else's mechanism, and reaching for a bigger implicit wait when the failure is one of those is the misreading the setting is famous for.

## What the call actually sets `driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10))` writes one number into the browser session's **timeouts configuration** — the field the WebDriver specification calls the *implicit wait timeout*. It is not a sleep, and it is not a loop living in your test code. It is a parameter handed to the driver process behind the session (chromedriver, geckodriver, or the driver on the node your Selenium Grid routed you to), which then consults it every time your test asks it to locate an element. The routine the remote end runs for a search looks like this: 1. Start a timer set to the implicit wait timeout. 2. Run the locator against the document and collect everything that matches. 3. If the collection is still empty and the timer has not fired, run the locator again. 4. Stop as soon as the collection is non-empty, or when the timer fires. That is the entire mechanism. Nothing in it inspects the elements it found, so an implicit wait can only ever answer the question "does anything match this locator yet?". ## The default is zero A brand-new session starts with the implicit wait timeout set to **0 milliseconds**. With zero, step 3 above never runs: the locator is evaluated once, and if nothing matches, `findElement` comes back as a `no such element` error, which the Java client raises as `NoSuchElementException`. So the out-of-the-box behaviour is fail-fast, and every retry you see in a Selenium suite is something somebody configured on purpose. Two consequences follow from "one number, session-wide": - It is **sticky**. One call near session setup changes every later `findElement` and `findElements` on that driver, including searches inside page objects and helper code you did not write. - It is **readable**. `driver.manage().timeouts().getImplicitWaitTimeout()` returns the current `Duration`, which is how you check what a shared harness has already done to your session. - It is **validated**. A negative value, or one past the maximum safe integer, is rejected by the driver as an invalid argument rather than silently clamped. ## The same knob in the other bindings The wire command is identical in every language; only the spelling and the unit differ. | Binding | How you set it | What you pass | |---|---|---| | Java | `driver.manage().timeouts().implicitlyWait(...)` | a `java.time.Duration` | | Python | `driver.implicitly_wait(10)` | seconds, as a number | | .NET | `driver.Manage().Timeouts().ImplicitWait = ...` | a `TimeSpan` | The Python spelling is the one that trips people up: `implicitly_wait` takes **seconds**, and it is the client that multiplies by a thousand before sending `implicit` to the driver. Selenium 4 removed the old Java `implicitlyWait(long, TimeUnit)` overload, so if you find that two-argument form in a codebase you are looking at Selenium 3 code that will not compile against a current client. ## Setting it before the first command You do not have to wait until the session exists. Every Selenium 4 browser options object inherits `setImplicitWaitTimeout(Duration)`, which puts the value into the `timeouts` capability requested when the session is created: ```java ChromeOptions options = new ChromeOptions(); options.setImplicitWaitTimeout(Duration.ofSeconds(5)); ``` That matters because it means the setting can arrive from somewhere other than the obvious `manage().timeouts()` line — a capability block in a config file counts too, and an absent `implicitlyWait` call is therefore not proof that the session is running with zero. ## What it does not cover Reading the marina berth allocation grid makes the boundary concrete. Suppose the page lists berths A1 to A40 with a status cell and an **Assign** button per row, and the grid is drawn by a script after the page's own load completes. - With an implicit wait set, `driver.findElement(By.cssSelector("#berth-grid tr[data-berth='A17']"))` keeps retrying while the grid renders, and succeeds once that row exists. - The moment the row exists, the wait is **over**. If the status cell still reads a dash because a second request has not returned, `getText()` gives you the dash; the implicit wait does not retry it. - If the **Assign** button is present but disabled while the berth is still being priced, the click throws `ElementNotInteractableException` immediately. Presence was satisfied, so nothing retries. - If the grid re-renders between the find and the click, the element reference you hold is stale and the click throws `StaleElementReferenceException` — again with no retry. The one-line version for an interview: **an implicit wait retries the search, never the result.** Everything a real page makes you wait for beyond mere presence — visible, populated, enabled, settled — is somebody else's mechanism, and reaching for a bigger implicit wait when the failure is one of those is the misreading the setting is famous for.

How would you find out whether a shared test harness has already set an implicit wait on the driver you were handed?
Call `driver.manage().timeouts().getImplicitWaitTimeout()`. It reads the `implicit` field back from the driver's own timeouts, so it reports what the session is really using rather than what your setup code believes it requested. Remember the value can also have arrived in the `timeouts` capability at session creation, not just from an `implicitlyWait` call.
What happens if you pass a negative Duration to implicitlyWait?
The driver rejects it. The protocol requires the value to be a number between zero and the maximum safe integer, so a negative duration comes back as an invalid argument error rather than being clamped to zero or treated as infinite. The same applies to an absurdly large value.
Does setting an implicit wait make a fast page slower?
No. The driver's search loop exits as soon as the locator matches something, so on a page where the element is already present the call returns in one evaluation. The cost only appears when nothing matches, because then the loop runs until the timer fires.

saying these in an interview costs you the question

Says the default implicit wait is ten or thirty seconds
Thinks implicitlyWait pauses the test for the full duration
Believes an implicit wait also waits for visibility or clickability
Calls implicitlyWait before every find, thinking it is per-call
Still writes implicitlyWait with a long and a TimeUnit

In Selenium, what does driver.manage().timeouts().implicitlyWait(Duration) change, and what is its default?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the call actually sets

The default is zero

The same knob in the other bindings

Setting it before the first command

What it does not cover

▾common follow-ups3 questions

▾red flags5 flags

What the call actually sets

The default is zero

The same knob in the other bindings

Setting it before the first command

What it does not cover

answer

go deeper