In Selenium, where does an implicit wait's retry loop run, and how long does the setting stay in force?

middleshould knowfreq 38%

answer

the client sends one command and stops
one slow request, not many quick ones
it belongs to the session, not the call
stored in the timeouts configuration
under the key implicit, in milliseconds

basics

~20 s

The loop runs in the driver on the remote end, not in the client library. The value is session state, so it applies to every later element search on that driver until something changes it or the session ends.

solid answer

~40 s

Calling implicitlyWait(Duration) sends one command — a POST to /session/{id}/timeouts with {"implicit": 10000} — and returns. From then on the driver process owns the retry loop, so a search that retries for eight seconds is a single HTTP request that takes eight seconds to answer, not a stream of polls from your client. The number lives in the session's timeouts configuration beside the page-load and script timeouts, which means it survives navigation, applies to searches inside code you did not write, and lasts until the session ends or somebody sets it again. getImplicitWaitTimeout() reads it back from the driver, and setImplicitWaitTimeout(Duration) on a browser options object supplies it in the timeouts capability before the first command runs.

Calling `implicitlyWait(Duration)` sends one command — a `POST` to `/session/{id}/timeouts` with `{"implicit": 10000}` — and returns. From then on the driver process owns the retry loop, so a search that retries for eight seconds is a single HTTP request that takes eight seconds to answer, not a stream of polls from your client. The number lives in the session's timeouts configuration beside the page-load and script timeouts, which means it survives navigation, applies to searches inside code you did not write, and lasts until the session ends or somebody sets it again. `getImplicitWaitTimeout()` reads it back from the driver, and `setImplicitWaitTimeout(Duration)` on a browser options object supplies it in the `timeouts` capability before the first command runs.

code

java · 23 lines

java

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

public class BerthGridSessionTimeouts {

  public static void main(String[] args) {
    ChromeOptions options = new ChromeOptions();
    options.setImplicitWaitTimeout(Duration.ofSeconds(5));

    WebDriver driver = new ChromeDriver(options);
    try {
      Duration fromCapability = driver.manage().timeouts().getImplicitWaitTimeout();
      System.out.println(fromCapability.toMillis());

      driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(12));
      System.out.println(driver.manage().timeouts().getImplicitWaitTimeout().toMillis());
    } finally {
      driver.quit();
    }
  }
}

go deeper

for a junior

Remember that one call configures the whole session rather than the next search, and that you never need to call it again unless you want a different value.

for a middle

Be able to describe the split: the client sends a single timeouts command, and the driver owns the retry loop. That explains why a long search shows up as one slow request in a log.

for a senior

Demonstrate that you treat the value as invisible shared state on a reused session, verify it with a read-back rather than trusting setup code, and restore it after any temporary change.

for a principal

Own the harness convention: whether an implicit wait is set at all, whether it comes from a capability or from code, and how a team keeps a session-wide setting from becoming an untracked dependency of every test.

The loop is not in your client library

When you call driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)), the Java client does exactly one thing: it sends a single command and returns. In RemoteWebDriver that is a POST to /session/{session id}/timeouts carrying {"implicit": 10000} — milliseconds, as an integer. There is no retry loop anywhere in the client, no scheduled poll, no background thread.

Everything after that happens on the remote end — the driver process for your browser, and on Selenium's Grid that is the driver running on the node that owns the session. When a later findElement arrives, the driver starts its own timer and re-evaluates the locator against the live document until something matches or the timer fires.

What the wire actually looks like

The consequences that matter for performance and for reading a log:

Setting the wait is one request, sent once.
A find that retries for eight seconds is still one request from the client's point of view — a single POST /session/{id}/element that takes eight seconds to answer.
Your HTTP log therefore shows a single slow command, not dozens of quick ones. Many rapid repeated find requests mean something in your own code is looping, not the implicit wait.
Because the retries never cross the network, the driver can poll far more tightly than a client-side loop could afford — and the specification deliberately does not define an interval, so the rate is the driver's business and not a number you can rely on.

Session state, and how long it lasts

The value lives in the session's timeouts configuration alongside the page-load and script timeouts, under the key implicit. That has four practical effects:

It applies to every subsequent element search on that session, including searches inside library code, page objects and framework helpers you did not write.
It survives navigation. Loading a different page of the marina berth allocation grid does not reset it.
It lasts until the session ends or until something sets it again. There is no scope, no stack and no automatic restore.
If a driver is reused across several tests, whatever the first test set is still in force for the rest — including a Duration.ZERO somebody set for a negative check and forgot to put back.

Reading it back, and the two places it can come from

Because the value is remote state, you can ask for it rather than guess:

What you want	Java call	Where the value lives
Read the current value	`getImplicitWaitTimeout()`	a `GET` of the session's timeouts
Change it mid-session	`implicitlyWait(Duration)`	a `POST` of the session's timeouts
Set it before the first command	`options.setImplicitWaitTimeout(Duration)`	the `timeouts` capability at session creation

getImplicitWaitTimeout() reads the implicit field out of the driver's own answer, so it reports what the remote end is really using — not what your code believes it asked for. That is the honest way to settle "is a wait already set?" in a harness assembled from several layers. Note the two entry points: a value can arrive from a timeouts capability declared in a config file, so the absence of an implicitlyWait call in the test code is not proof that the timeout is zero.

Why this framing is the one interviewers want

Describing an implicit wait as "a global setting in Selenium" is not wrong, but it explains none of the behaviour people actually hit. Describing it as remote session state that parameterises the driver's own search loop explains all of it at once:

Why a single find call can take ten seconds while the client thread sits idle inside one HTTP request.
Why the setting cannot be scoped to one block of code — there is nothing local to scope, only a value you set and later set back.
Why two drivers in a parallel run have completely independent values: two sessions, two timeouts configurations, no shared state between them.
Why setting it costs one round trip and is worth doing once at session setup rather than before every find call.
Why a berth-grid test that passes alone can behave differently in a suite that reuses one driver and left the value somewhere unexpected.

The one-sentence version: you configure it from the client, but it executes in the driver, for the life of the session.

## The loop is not in your client library When you call `driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10))`, the Java client does exactly one thing: it sends a single command and returns. In `RemoteWebDriver` that is a `POST` to `/session/{session id}/timeouts` carrying `{"implicit": 10000}` — milliseconds, as an integer. There is no retry loop anywhere in the client, no scheduled poll, no background thread. Everything after that happens on the **remote end** — the driver process for your browser, and on Selenium's Grid that is the driver running on the node that owns the session. When a later `findElement` arrives, the driver starts its own timer and re-evaluates the locator against the live document until something matches or the timer fires. ## What the wire actually looks like The consequences that matter for performance and for reading a log: - Setting the wait is **one** request, sent once. - A find that retries for eight seconds is still **one** request from the client's point of view — a single `POST /session/{id}/element` that takes eight seconds to answer. - Your HTTP log therefore shows a single slow command, not dozens of quick ones. Many rapid repeated find requests mean something in your own code is looping, not the implicit wait. - Because the retries never cross the network, the driver can poll far more tightly than a client-side loop could afford — and the specification deliberately does **not** define an interval, so the rate is the driver's business and not a number you can rely on. ## Session state, and how long it lasts The value lives in the session's timeouts configuration alongside the page-load and script timeouts, under the key `implicit`. That has four practical effects: 1. It applies to **every** subsequent element search on that session, including searches inside library code, page objects and framework helpers you did not write. 2. It survives navigation. Loading a different page of the marina berth allocation grid does not reset it. 3. It lasts until the session ends or until something sets it again. There is no scope, no stack and no automatic restore. 4. If a driver is reused across several tests, whatever the first test set is still in force for the rest — including a `Duration.ZERO` somebody set for a negative check and forgot to put back. ## Reading it back, and the two places it can come from Because the value is remote state, you can ask for it rather than guess: | What you want | Java call | Where the value lives | |---|---|---| | Read the current value | `getImplicitWaitTimeout()` | a `GET` of the session's timeouts | | Change it mid-session | `implicitlyWait(Duration)` | a `POST` of the session's timeouts | | Set it before the first command | `options.setImplicitWaitTimeout(Duration)` | the `timeouts` capability at session creation | `getImplicitWaitTimeout()` reads the `implicit` field out of the driver's own answer, so it reports what the remote end is really using — not what your code believes it asked for. That is the honest way to settle "is a wait already set?" in a harness assembled from several layers. Note the two entry points: a value can arrive from a `timeouts` capability declared in a config file, so the absence of an `implicitlyWait` call in the test code is not proof that the timeout is zero. ## Why this framing is the one interviewers want Describing an implicit wait as "a global setting in Selenium" is not wrong, but it explains none of the behaviour people actually hit. Describing it as **remote session state that parameterises the driver's own search loop** explains all of it at once: - Why a single find call can take ten seconds while the client thread sits idle inside one HTTP request. - Why the setting cannot be scoped to one block of code — there is nothing local to scope, only a value you set and later set back. - Why two drivers in a parallel run have completely independent values: two sessions, two timeouts configurations, no shared state between them. - Why setting it costs one round trip and is worth doing once at session setup rather than before every find call. - Why a berth-grid test that passes alone can behave differently in a suite that reuses one driver and left the value somewhere unexpected. The one-sentence version: **you configure it from the client, but it executes in the driver, for the life of the session.**

If the retry loop is inside the driver, what poll interval does it use?
The protocol does not define one. The search routine simply repeats while the result is empty and the timer has not fired, so the rate is entirely up to the driver implementation. Do not build a test around an assumed interval; the only guarantee is the upper bound you set.
Two tests run in parallel against two drivers. Does setting an implicit wait in one affect the other?
No. Each driver holds its own session, and the timeouts configuration is per-session state on the remote end. The two values are independent. The trap is the opposite case: one driver reused across several tests carries whatever the previous test left behind.
Where else can an implicit wait come from besides an implicitlyWait call?
From the `timeouts` capability requested at session creation. Every Selenium 4 browser options object has `setImplicitWaitTimeout(Duration)`, which puts an `implicit` entry into that capability, so a value can be configured entirely outside the test code.

saying these in an interview costs you the question

Thinks the client library polls the browser in a loop
Says the implicit wait resets on navigation or page load
Expects a per-call scope that restores itself afterwards
Assumes a fixed poll interval such as 500 milliseconds
Believes it can only be set through a manage().timeouts() call

In Selenium, where does an implicit wait's retry loop run, and how long does the setting stay in force?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The loop is not in your client library

What the wire actually looks like

Session state, and how long it lasts

Reading it back, and the two places it can come from

Why this framing is the one interviewers want

▾common follow-ups3 questions

▾red flags5 flags

The loop is not in your client library

What the wire actually looks like

Session state, and how long it lasts

Reading it back, and the two places it can come from

Why this framing is the one interviewers want

answer

go deeper