selenium implicit vs explicit wait mixing causing flake
Explains why mixing implicit and explicit waits makes Selenium suites flaky and how to standardize on explicit waits. Use when the same tests pass and fail across runs with wait timeouts in inconsistent places. Not for Playwright or Cypress, not for deterministic failures, and not for animation timing issues alone.
TL;DR
Set the implicit wait to zero and use explicit waits everywhere. Mixing the two makes timeouts stack unpredictably, which is the classic source of Selenium flake. Pick one strategy per session; explicit wins.
Problem
The suite is flaky: the same test passes and fails across runs, with waits timing out in inconsistent places.
Steps
- Set the implicit wait to 0 right after creating the driver. Expected: the timeouts API shows 0 as the only implicit setting.
- Replace every reliance on implicit waiting with explicit WebDriverWait plus expected conditions. Expected: each wait has a named condition and a timeout.
- Search the codebase for any other implicit wait or sleep calls and remove them. Expected: no implicit waits and no raw sleeps remain.
- Re-run the flaky suite several times. Expected: results stabilize across runs.
When to use
- A Selenium 4 suite flakes with mixed wait strategies.
- Timeouts vary run to run without code changes.
- You inherited a suite with implicit waits sprinkled around.
When not to use
- Flake comes from real timing issues like animations; explicit waits still help but the condition needs care.
- You use Playwright or Cypress; they auto-wait and this advice does not apply.
- A single deterministic failure; that is a locator or app bug, not wait flake.
Tool compatibility
- Selenium 4.x, all language bindings: implicit wait via the timeouts API, explicit via WebDriverWait.
- Works for Chrome, Firefox, and Edge drivers.
Variant phrasings
should I use implicit or explicit waits in selenium
Explicit. Implicit waits apply globally and interact badly with explicit ones.
selenium waits timing out randomly
Audit for mixed waits first; it is the most common cause before blaming the app.
Why it happens
An implicit wait makes every element lookup poll up to its timeout. When an explicit wait polls for a condition that itself does lookups, the two timeouts multiply, so total wait time becomes unpredictable and tests flake.
Edge cases
- Third-party page objects may set implicit waits internally; audit dependencies too.
- Zero implicit wait means an immediate NoSuchElement on missing elements; that is correct, let the explicit wait handle retries.
- File uploads and downloads need condition-based waits, not longer implicit timeouts.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_iHBlijxOmfvhYUZ86oVEEw
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.