In Selenium, what happens if you set an implicit wait and also use WebDriverWait in the same session?

juniormust knowfreq 76%

answer

Selenium's docs use one blunt word here
Two mechanisms, two different machines
Ten plus fifteen does not give fifteen
The default implicit value is zero
Keep one waiting mechanism per step

basics

~10 s

Wait times become unpredictable. Selenium's documentation warns against mixing the two, and gives the example of a 10-second implicit wait with a 15-second explicit wait producing a timeout after 20 seconds.

solid answer

~50 s

Selenium 4 has two waiting mechanisms and they are not designed to combine. An implicit wait is a session setting that makes the remote end retry every element lookup for up to its timeout; an explicit WebDriverWait is a loop in your own code that polls a condition every 500 ms until its own deadline. Run both and the loops nest — each poll of the explicit wait triggers a find that burns the whole implicit wait — so timeouts arrive late and stop matching the numbers you configured. The documented warning is blunt: do not mix implicit and explicit waits, because doing so can cause unpredictable wait times. The default implicit wait is Duration.ZERO, so the safe shape is to leave it there and put a WebDriverWait at each step that is genuinely asynchronous.

Selenium 4 has two waiting mechanisms and they are not designed to combine. An implicit wait is a session setting that makes the remote end retry every element lookup for up to its timeout; an explicit `WebDriverWait` is a loop in your own code that polls a condition every 500 ms until its own deadline. Run both and the loops nest — each poll of the explicit wait triggers a find that burns the whole implicit wait — so timeouts arrive late and stop matching the numbers you configured. The documented warning is blunt: do not mix implicit and explicit waits, because doing so can cause unpredictable wait times. The default implicit wait is `Duration.ZERO`, so the safe shape is to leave it there and put a `WebDriverWait` at each step that is genuinely asynchronous.

code

java · 23 lines

java

import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

public class BookRinkSession {
  public static void main(String[] args) {
    WebDriver driver = new ChromeDriver();
    try {
      driver.manage().timeouts().implicitlyWait(Duration.ZERO);
      driver.get("https://rink.example/sessions");
      new WebDriverWait(driver, Duration.ofSeconds(10))
          .until(ExpectedConditions.elementToBeClickable(By.id("book-friday-1830")))
          .click();
      new WebDriverWait(driver, Duration.ofSeconds(10))
          .until(ExpectedConditions.visibilityOfElementLocated(By.id("booking-confirmed")));
    } finally {
      driver.quit();
    }
  }
}

go deeper

for a junior

Be ready to state the rule and the reason in one breath: do not mix implicit and explicit waits, because the wait times become unpredictable. Knowing the default implicit value is zero is expected too.

for a middle

Explain the mechanics behind the rule — one wait is a session setting honoured by the remote end, the other is a client-side polling loop — and why nesting them makes a timeout land late.

for a senior

An interviewer expects you to describe how you would find the mixing in an inherited suite and what the safe end state is, including the fixed sleeps usually sitting on top of both.

for a principal

Own the one-mechanism-per-step convention as something enforced in the shared driver setup, and be able to justify it in terms of run reports that can be reasoned about.

The two mechanisms Selenium gives you

Selenium 4 offers exactly two supported ways to wait for the ice-rink booker's slot list to appear, and they work in completely different places.

An implicit wait is a setting on the session. driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)) tells the remote end — the browser driver — to keep retrying every element lookup for up to 10 seconds before reporting that nothing matched. It is set once and applies to every find for the life of the session.
An explicit wait is a loop in your code. new WebDriverWait(driver, Duration.ofSeconds(10)).until(condition) evaluates a condition, sleeps 500 ms, evaluates it again, and gives up with a TimeoutException when its deadline passes. It applies only where you write it, and it can wait for things a find cannot express, such as an element being clickable.

Where each one lives

	Implicit wait	Explicit wait
Runs in	the remote end (the driver process)	your test process
Scope	the whole session, every find	the one call you wrote
Default	`Duration.ZERO` — no retrying at all	none exists until you create one
Waits for	an element lookup to return something	any condition you can express
How it ends	the element is found, or the timer fires	the condition returns a non-null, non-false value, or `TimeoutException`

What happens when both are on

Selenium's documentation is direct about it: do not mix implicit and explicit waits, because doing so can cause unpredictable wait times. The example it gives is that an implicit wait of 10 seconds and an explicit wait of 15 seconds can produce a timeout after 20 seconds.

The reason is that the loops nest. Every poll of the explicit wait calls a find, and that find is where the implicit wait is spent — so one "quick check" by the outer loop actually blocks for a full 10 seconds. The outer loop only looks at its own deadline once the poll returns, and by then it has already overshot. Three consequences follow:

A timeout arrives later than the number you configured, by roughly one implicit wait.
The TimeoutException message still quotes the configured timeout, so the log disagrees with the clock.
Checks that succeed by not finding something — asserting a cancelled slot's badge has gone — pay the whole implicit wait every time, even when they pass.

The default to keep

Leave the implicit wait alone. Duration.ZERO is the default in the W3C specification and in every Selenium binding, so a session you never touch is already correct.
Put a WebDriverWait at each step that is genuinely asynchronous, with a condition that names what you are waiting for — the booking confirmation present, the Book button clickable.
If you inherit a suite that sets an implicit wait in a shared factory, set it to Duration.ZERO there rather than deleting explicit waits, and read the session back with getImplicitWaitTimeout() to be sure the value took effect.

Two details make that default easy to hold. The implicit wait is one of three members of the session's timeouts configuration, alongside the page load timeout and the script timeout, so leaving it at zero does not disable navigation or script waiting — those keep their own separate defaults. And an explicit wait already retries the lookup itself: WebDriverWait is constructed ignoring NotFoundException, so a condition whose find comes back empty simply polls again rather than failing. Nothing is lost by taking the implicit retrying away.

A fixed sleep is a third layer

Thread.sleep(2000) in the same method adds a third, unconditional layer on top of the other two. Unlike either wait it has no exit condition, so it always costs its full duration whether the Friday-evening slot rendered in 50 ms or not at all, and it cannot shorten the implicit wait that the next find will still pay. Replacing it is mechanical: the sleep is standing in for a condition, and writing that condition into a WebDriverWait gives you both the early exit the sleep never had and a TimeoutException that says which condition failed instead of an assertion error two lines later.

The end state is one waiting mechanism per step: zero implicit wait, no sleeps, and an explicit wait wherever the page is asynchronous — which is also the only configuration in which a timeout number in a Selenium run means what it says.

## The two mechanisms Selenium gives you Selenium 4 offers exactly two supported ways to wait for the ice-rink booker's slot list to appear, and they work in completely different places. - An **implicit wait** is a setting on the *session*. `driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10))` tells the remote end — the browser driver — to keep retrying every element lookup for up to 10 seconds before reporting that nothing matched. It is set once and applies to every find for the life of the session. - An **explicit wait** is a loop in *your* code. `new WebDriverWait(driver, Duration.ofSeconds(10)).until(condition)` evaluates a condition, sleeps 500 ms, evaluates it again, and gives up with a `TimeoutException` when its deadline passes. It applies only where you write it, and it can wait for things a find cannot express, such as an element being clickable. ## Where each one lives | | Implicit wait | Explicit wait | |---|---|---| | Runs in | the remote end (the driver process) | your test process | | Scope | the whole session, every find | the one call you wrote | | Default | `Duration.ZERO` — no retrying at all | none exists until you create one | | Waits for | an element lookup to return something | any condition you can express | | How it ends | the element is found, or the timer fires | the condition returns a non-null, non-false value, or `TimeoutException` | ## What happens when both are on Selenium's documentation is direct about it: **do not mix implicit and explicit waits, because doing so can cause unpredictable wait times.** The example it gives is that an implicit wait of 10 seconds and an explicit wait of 15 seconds can produce a timeout after 20 seconds. The reason is that the loops nest. Every poll of the explicit wait calls a find, and that find is where the implicit wait is spent — so one "quick check" by the outer loop actually blocks for a full 10 seconds. The outer loop only looks at its own deadline once the poll returns, and by then it has already overshot. Three consequences follow: - A timeout arrives later than the number you configured, by roughly one implicit wait. - The `TimeoutException` message still quotes the configured timeout, so the log disagrees with the clock. - Checks that succeed by *not* finding something — asserting a cancelled slot's badge has gone — pay the whole implicit wait every time, even when they pass. ## The default to keep 1. Leave the implicit wait alone. `Duration.ZERO` is the default in the W3C specification and in every Selenium binding, so a session you never touch is already correct. 2. Put a `WebDriverWait` at each step that is genuinely asynchronous, with a condition that names what you are waiting for — the booking confirmation present, the **Book** button clickable. 3. If you inherit a suite that sets an implicit wait in a shared factory, set it to `Duration.ZERO` there rather than deleting explicit waits, and read the session back with `getImplicitWaitTimeout()` to be sure the value took effect. Two details make that default easy to hold. The implicit wait is one of three members of the session's timeouts configuration, alongside the page load timeout and the script timeout, so leaving it at zero does not disable navigation or script waiting — those keep their own separate defaults. And an explicit wait already retries the lookup itself: `WebDriverWait` is constructed ignoring `NotFoundException`, so a condition whose find comes back empty simply polls again rather than failing. Nothing is lost by taking the implicit retrying away. ## A fixed sleep is a third layer `Thread.sleep(2000)` in the same method adds a third, unconditional layer on top of the other two. Unlike either wait it has no exit condition, so it always costs its full duration whether the Friday-evening slot rendered in 50 ms or not at all, and it cannot shorten the implicit wait that the next find will still pay. Replacing it is mechanical: the sleep is standing in for a condition, and writing that condition into a `WebDriverWait` gives you both the early exit the sleep never had and a `TimeoutException` that says which condition failed instead of an assertion error two lines later. The end state is one waiting mechanism per step: zero implicit wait, no sleeps, and an explicit wait wherever the page is asynchronous — which is also the only configuration in which a timeout number in a Selenium run means what it says.

If you had to keep one of the two mechanisms, which would you keep and why?
The explicit wait. It sits at the step that is actually asynchronous, it can express conditions a lookup cannot — clickable, invisible, text present — and its failure names the condition that never became true. An implicit wait can only retry lookups and gives no clue why a step was slow.
What is the default implicit wait in a fresh Selenium session?
Zero. The W3C timeouts configuration starts with an implicit wait timeout of 0, a page load timeout of 300000 ms and a script timeout of 30000 ms, so a session you never configure does no lookup retrying at all and a missing element fails immediately.
Does a Thread.sleep before a WebDriverWait shorten the wait that follows it?
No. The sleep always costs its full duration, and the wait that follows still starts its own deadline and still pays whatever the session's implicit wait costs on each find. Sleeping first adds time unconditionally rather than removing any.

It is like a nested pair of egg timers: the outer one is only glanced at once the inner one has finished ringing, so the outer time is never the time you actually wait.

saying these in an interview costs you the question

Says the two waits combine safely and the larger one simply wins
Thinks an implicit wait covers clickability or visibility as well
Claims the implicit wait default is a few seconds rather than zero
Sets an implicit wait as a safety net under existing explicit waits
Treats Thread.sleep as interchangeable with a WebDriverWait

In Selenium, what happens if you set an implicit wait and also use WebDriverWait in the same session?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The two mechanisms Selenium gives you

Where each one lives

What happens when both are on

The default to keep

A fixed sleep is a third layer

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

The two mechanisms Selenium gives you

Where each one lives

What happens when both are on

The default to keep

A fixed sleep is a third layer

answer

go deeper