Selenium chrome not reachable WebDriverException: Causes and Fixes

TL;DR

A selenium chrome not reachable WebDriverException means the WebDriver client could not communicate with the Chrome process through ChromeDriver. Determine whether startup failed or an established browser crashed, collect verbose driver and host evidence, then fix the actual cause: incompatible binaries, profile locks, insufficient container resources, sandbox or permissions, grid loss, or browser termination.

Key Takeaways

• Classify whether Chrome failed during session creation or became unreachable after commands had already succeeded.
• Enable ChromeDriver verbose logs and preserve browser, container, operating system, and grid evidence from the same failure.
• Reproduce with a minimal page and default options before changing timeouts or adding Chrome flags.
• Give each parallel session its own profile, adequate memory, and an isolated process lifecycle.
• Run Chrome as a non-root user with a working sandbox instead of defaulting to `--no-sandbox`.
• Use a managed compatible Chrome and ChromeDriver pair, but do not mistake every crash for a version mismatch.
• Retry only a classified transient infrastructure loss, once and with the first failure still reported.

A selenium chrome not reachable WebDriverException means Selenium and ChromeDriver could not establish or continue communication with the Chrome browser process. It is a transport symptom, not a single root cause. Chrome may have exited at startup, crashed under resource pressure, lost its DevTools connection, been killed by the operating system, or become inaccessible through a remote node.

Do not begin with a random list of Chrome flags. First determine when the failure occurred, save ChromeDriver and host evidence from that exact session, and reproduce with the smallest supported configuration. This guide provides a decision tree, current Selenium 4 Java logging code, container and CI checks, profile isolation, compatibility checks, and a safe recovery policy.

TL;DR

The fastest diagnosis comes from aligning ChromeDriver timestamps, test commands, Chrome process status, and operating system or container events.

1. Selenium chrome not reachable WebDriverException: Read the Failure Phase

The same wording can appear in different exception chains, so record the phase. A failure during new ChromeDriver(options) is a new-session problem. ChromeDriver started, attempted to launch or attach to Chrome, and could not establish a healthy browser connection. A failure after navigation and element commands succeeded means the session existed and later lost the browser.

Preserve the entire exception, including its type, message, cause, Selenium build information, system information, driver information, and session ID when one exists. Do not search only the last line. SessionNotCreatedException with a compatibility message suggests a version issue. WebDriverException containing chrome not reachable, disconnected, or a DevTools connection error after several commands points more strongly to browser or node loss.

Create a short incident record:

phase: new session | first navigation | mid-test | teardown
last successful command: ...
session id: ...
chrome version: ...
chromedriver version: ...
selenium version: ...
worker and host: ...
container id or grid node: ...
first failing timestamp: ...

The phase prevents false fixes. Increasing an element wait cannot restore a dead Chrome process. Replacing ChromeDriver may not help a container killed for memory. Conversely, investigating a page locator is irrelevant when no session was created.

2. Capture ChromeDriver Logs Before Changing Anything

ChromeDriver verbose logs show the selected Chrome binary, launch arguments, profile path, DevTools handshake, commands, responses, and many startup errors. Configure a unique log file per test worker so parallel sessions do not overwrite each other. Selenium's Java service builder provides current logging methods.

import java.nio.file.Files;
import java.nio.file.Path;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeDriverService;
import org.openqa.selenium.chrome.ChromeOptions;

Path log = Path.of("build", "webdriver", "chromedriver-worker-1.log")
        .toAbsolutePath();
Files.createDirectories(log.getParent());

ChromeDriverService service = new ChromeDriverService.Builder()
        .usingAnyFreePort()
        .withVerbose(true)
        .withReadableTimestamp(true)
        .withLogFile(log.toFile())
        .build();

ChromeOptions options = new ChromeOptions();
WebDriver driver = new ChromeDriver(service, options);

This log is for ChromeDriver. Chrome's own crash and process evidence can live elsewhere. Capture operating system events, container termination reason, grid node logs, standard error, and a crash dump if your approved environment enables one. Keep timestamps in a consistent timezone.

Treat logs as sensitive artifacts. Chrome launch arguments can contain proxy values or custom profile paths, and page-related logs can reveal URLs. Redact tokens and user data before publishing. Do not enable broad verbose logging permanently without a retention policy.

On a remote session, a local ChromeDriverService does not control the node's driver. Collect server-side Grid and node logs using the session ID and worker metadata.

3. Reproduce With a Minimal Chrome Health Test

Strip the test down to browser creation, a local data URL, one assertion, and guaranteed cleanup. Remove extensions, proxies, custom profiles, downloads, experimental options, and application dependencies. This separates Chrome startup health from page behavior.

import static org.junit.jupiter.api.Assertions.assertEquals;

import org.junit.jupiter.api.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

class ChromeHealthTest {
    @Test
    void chromeCanStartAndExecuteCommands() {
        ChromeOptions options = new ChromeOptions();
        options.addArguments("--headless=new");
        WebDriver driver = new ChromeDriver(options);
        try {
            driver.get("data:text/html,<title>health</title><h1>ready</h1>");
            assertEquals("health", driver.getTitle());
            assertEquals("ready", driver.findElement(By.tagName("h1")).getText());
        } finally {
            driver.quit();
        }
    }
}

Run it once on the failing worker, then repeatedly only enough to establish whether failure is consistent or load-dependent. If this test fails, the application and locator code are not the cause. If it passes but the full scenario fails, restore one configuration or workflow dimension at a time.

Also launch the exact Chrome binary shown in the ChromeDriver log directly as the same operating system user. Include only the arguments needed to reproduce. If Chrome cannot launch without WebDriver, repair the browser installation, permissions, libraries, user environment, or resource constraints before changing Selenium code.

A minimal reproduction should be attachable to an infrastructure or browser issue without client data, production URLs, or secrets.

4. Verify the Actual Chrome Binary and Driver Pair

Modern Selenium Manager can discover or obtain an appropriate driver for a local browser when no driver path is forced. Problems often arise when an older chromedriver earlier on PATH, a webdriver.chrome.driver system property, a cached CI layer, or a framework dependency overrides that management. Verify the executable used, not the version you intended to install.

Run diagnostic commands in the same worker environment:

chromedriver --version
google-chrome --version || google-chrome-stable --version || chromium --version
which chromedriver
which google-chrome || which google-chrome-stable || which chromium

Windows agents can use where chromedriver and inspect the installed browser version. macOS Chrome's executable is inside the application bundle. The ChromeDriver verbose log is the final authority for which browser binary it launched.

A clear session not created message stating that a ChromeDriver supports one Chrome version while the current browser has another is a compatibility problem. Follow the ChromeDriver version mismatch guide. Do not disable ChromeDriver's build check. That can turn a useful startup error into unpredictable protocol behavior.

A compatible pair can still produce chrome not reachable because compatibility does not prevent memory pressure, profile locks, sandbox failures, or external termination. Check the error text and process evidence before replacing binaries.

5. Fix Chrome Binary, Permissions, and Startup Environment

ChromeDriver logs the browser binary it uses. Confirm that path exists, is executable by the CI user, and points to the intended Chrome or Chrome for Testing asset. A desktop shortcut or application directory is not necessarily the executable. If Chrome is installed in a nonstandard location, set the real binary explicitly only through environment-aware configuration.

ChromeOptions options = new ChromeOptions();
String binary = System.getenv("CHROME_BINARY");
if (binary != null && !binary.isBlank()) {
    options.setBinary(binary);
}
WebDriver driver = new ChromeDriver(options);

Validate the path before session creation and report a safe, clear configuration error. Do not embed one developer's path in source control. In container images, install Chrome and its runtime libraries during the image build, then test browser launch as the same non-root runtime user.

On Linux, running Chrome as root commonly causes startup trouble because of sandbox expectations. The robust fix is to run the container or agent as a regular user with a functioning sandbox. --no-sandbox weakens an important browser security boundary and should not be the default repair. If a tightly controlled environment temporarily requires it, the security owner must approve and document the risk.

Check filesystem write permission for temporary directories, profile creation, and artifact paths. A read-only filesystem or full disk can make Chrome exit before DevTools becomes available. Capture free space and inode availability alongside the failure.

6. Resolve Container Memory and Shared Memory Failures

Chrome uses multiple processes and shared memory. In a constrained container, the browser can crash or be killed even though the test code is correct. Inspect the container state for an out-of-memory termination, cgroup memory events, kernel logs when accessible, and the worker's memory limit. Correlate the event time with ChromeDriver's disconnect.

Docker's default /dev/shm allocation may be smaller than Chrome workloads need. Prefer allocating a tested shared-memory size for the suite rather than redirecting all shared-memory use to disk. A Compose service can declare:

services:
  selenium-tests:
    image: your-approved-test-image:tag
    shm_size: 2gb
    init: true
    user: "1000:1000"

The value is a configuration example, not a universal requirement. Measure your pages, concurrency, video or tracing features, and container limits. --disable-dev-shm-usage can move shared-memory files to /tmp, which may help diagnose a /dev/shm constraint but can reduce performance and hide poor resource sizing.

Scale concurrency using measured peak resource use and failure behavior. Ten healthy serial sessions do not prove ten sessions fit concurrently. Track browser process count, memory, CPU throttling, session startup latency, and crash rate per node.

Use an init process or equivalent container design so child processes are reaped. Always call driver.quit(). Orphaned Chrome processes consume resources and make later sessions appear randomly unreachable.

7. Isolate Chrome User Profiles and Temporary Directories

Chrome profiles use locks and contain state. Two browser processes must not share the same user-data directory. Reusing a developer's normal profile can also trigger extension behavior, sync, first-run screens, policy differences, and corruption. ChromeDriver's default temporary profile is the safest starting point.

If the test genuinely requires a custom profile, create a unique directory per session and remove only that owned directory after the driver has quit.

Path profile = Files.createTempDirectory("selenium-chrome-");
ChromeOptions options = new ChromeOptions();
options.addArguments("--user-data-dir=" + profile.toAbsolutePath());
WebDriver driver = null;
try {
    driver = new ChromeDriver(options);
    driver.get("data:text/html,<h1>profile-ready</h1>");
} finally {
    if (driver != null) {
        driver.quit();
    }
    // Delete the owned directory with a tested recursive cleanup utility.
}

The cleanup comment is intentional because Java's standard deletion is not recursive. Use a reviewed utility that refuses paths outside the suite's artifact or temp root. Never delete a shared or personal profile.

If logs mention a profile already in use, do not add another flag to bypass the lock. Find the process holding it, correct session cleanup, and generate a unique path. Include worker and test identifiers in the directory name only if they contain safe characters and no sensitive data.

A persistent login profile is often inferior to API-based test setup or a controlled authentication fixture. Persistent profiles make tests dependent on expiring state and browser policy.

8. Diagnose Mid-Test Chrome Crashes and External Kills

When commands worked before the failure, identify the last successful command and the time Chrome disappeared. Check whether the page triggered exceptional memory use, a download exhausted disk, a native browser crash occurred, the CI platform canceled the process, or another cleanup hook killed every Chrome process on the host.

Do not use commands such as pkill chrome or taskkill /IM chrome.exe /F in shared teardown. They terminate sessions owned by other tests and users. End only the WebDriver session and processes owned by the current worker. In a container-per-worker model, container cleanup provides a safer ownership boundary.

Capture process exit and resource telemetry outside the browser session because Selenium cannot request a screenshot from a dead process. Useful evidence includes:

• Container exit reason and restart count.
• Kernel or platform out-of-memory events.
• Chrome crash dump identifier when approved.
• Free disk and temporary directory status.
• Node CPU throttling and memory near the failure.
• Last ChromeDriver command and response.
• Whether every session on the node disconnected together.

A specific page can expose a Chrome defect. Reproduce with the same browser build and a sanitized local page if possible, then compare the stable and next supported browser channel in an isolated investigation. Do not silently change production regression browsers without recording the coverage change.

If only one test causes the crash, simplify its page operations, file handling, extensions, and DevTools features until the trigger is isolated.

9. Separate Application Hangs From Browser Loss

A slow application and an unreachable browser produce different signals. If an explicit wait times out but driver.getTitle() or another harmless command still succeeds, Chrome is reachable. Diagnose the expected application state, network request, locator, or timeout. If every command throws a connection or invalid-session error and the Chrome process is gone, wait tuning is irrelevant.

Use a narrow probe only for diagnosis:

static boolean sessionResponds(WebDriver driver) {
    try {
        driver.getWindowHandle();
        return true;
    } catch (WebDriverException unreachable) {
        return false;
    }
}

Do not use this method to keep executing a test after a browser failure. Once session integrity is lost, create a new session for a new attempt. The old state, windows, cookies, downloads, and in-progress application operations are no longer trustworthy.

Page load timeouts, script timeouts, and WebDriverWait bounds apply to different operations. A page load timeout can interrupt navigation without necessarily crashing Chrome. Preserve the exact exception and test whether the session remains responsive. The Selenium timeout exception guide explains that distinction.

A health probe sent too frequently adds noise and can mask the last meaningful command. Prefer driver logs and platform telemetry, with one controlled probe during investigation.

10. Investigate Selenium Grid and Network Boundaries

With RemoteWebDriver, there are two communication paths: test client to Grid, and the Grid node's ChromeDriver to Chrome. A client-side network interruption can look like a failed WebDriver command even when Chrome remains alive. A node crash can remove Chrome and ChromeDriver together. Locate the failure boundary before restarting anything.

Record the Selenium session ID, Grid node or slot, client worker, requested sanitized capabilities, timestamps, and the last command. Query approved Grid observability and correlate distributor, router, node, and container logs. If all sessions on one node fail, investigate that node. If clients across nodes lose the router, investigate the network or Grid front door.

Do not expose a local ChromeDriver port beyond its intended host. ChromeDriver is not an authentication boundary for untrusted networks. Use Selenium Grid's supported architecture and network controls.

Review infrastructure timeouts separately from WebDriver timeouts. Proxies, load balancers, CI job cancellation, pod eviction, and idle connection policies can interrupt a session. Keepalive changes are justified only by evidence and security review.

A remote retry should obtain a fresh slot and fresh data. If the node is unhealthy, rescheduling to the same node can repeat the failure. Node health automation belongs to the platform, not to test code that restarts shared services.

11. Apply Fixes in a Controlled Order

Change one causal dimension at a time. Begin with the minimal test and default options. Confirm actual binaries and direct Chrome launch. Then validate profile uniqueness, filesystem access, runtime user, shared memory, total memory, concurrency, and remote node stability. Add application features and optional Chrome arguments back individually.

Remove diagnostic flags after the investigation unless they are a deliberate supported configuration. Keep the ChromeDriver log available on failure, but apply retention and redaction.

Validate the fix with the minimal health test, the original scenario, parallel load when relevant, and at least one neighboring scenario. A fix that only suppresses the message without preserving session correctness is not complete.

12. Selenium chrome not reachable WebDriverException Prevention Checklist

Use a maintained Selenium 4 release and one clear driver-management mechanism. Let Selenium Manager manage ordinary local compatibility or install a tested Chrome for Testing pair together in a hermetic image. Remove stale PATH entries, properties, and duplicated caches that can override the intended executable.

Build CI images with a non-root user, the required Chrome runtime libraries, writable owned temporary directories, sufficient shared memory, a process reaper, and a tested browser health check. Pin the image by immutable identifier and update it through a controlled pipeline.

Give each test its own driver and data. Give every custom profile, download directory, log file, and artifact path unique ownership. Call quit() in guaranteed teardown and monitor for leaked processes. Cap parallelism at verified node capacity.

On failure, automatically retain:

1. Full WebDriver exception and session ID.
2. ChromeDriver verbose log for that session or worker.
3. Actual browser and driver versions.
4. Container or host termination and resource evidence.
5. Grid node identity for remote sessions.
6. Last successful command and safe scenario identifier.

Track browser-loss failures separately from application timeouts and assertions. Trend them by browser build, image, grid node, and test. The flaky test root cause workflow can turn repeated symptoms into owned infrastructure work.

Interview Questions and Answers

Q: What does chrome not reachable mean in Selenium?

It means ChromeDriver could not establish or continue its control connection to Chrome. It is a symptom that can result from startup failure, a browser crash, resource termination, profile conflict, incompatible binaries, or remote-node loss. I classify the phase and collect driver plus host evidence before choosing a fix.

Q: What is the first artifact you enable?

I enable a unique ChromeDriver verbose log with readable timestamps. I pair it with the full exception, actual binary versions, process or container status, and the last successful command. Driver logs alone may not show an operating system kill.

Q: Would you add --no-sandbox to fix Chrome startup in Docker?

Not as the default fix. Running Chrome as a non-root user with a working sandbox preserves a security boundary and is the preferred environment design. Any exception needs explicit security ownership and documentation.

Q: How does /dev/shm affect Chrome?

Chrome uses shared memory for multiprocess browser work. An undersized shared-memory mount under concurrent or heavy pages can contribute to crashes. I confirm evidence, size the container for measured load, and treat --disable-dev-shm-usage only as a diagnostic or consciously accepted tradeoff.

Q: Can an explicit wait fix chrome not reachable?

No. An explicit wait can synchronize with application state only while the session is healthy. If the browser process or communication channel is gone, the attempt must stop and the infrastructure cause must be fixed.

Q: How do you distinguish a version mismatch from a Chrome crash?

A mismatch normally produces a clear new-session compatibility message naming supported and current browser versions. A mid-test unreachable error after successful commands points to browser or node loss. I still verify actual executables because PATH and caches can override expectations.

Q: Should a framework retry this exception?

Only if evidence classifies a transient infrastructure loss and policy permits one fresh-session retry. The first failure remains reported, the retry uses isolated data, and deterministic startup defects are not retried. Blanket retries hide capacity and browser stability problems.

Q: How would you diagnose the issue on Selenium Grid?

I correlate the session ID across client, router, distributor, node, ChromeDriver, and container evidence. I determine whether one session, one node, or the Grid entry path failed. Recovery and node draining belong to platform automation, not individual tests.

Common Mistakes

• Treating chrome not reachable as one fixed problem.
• Reading only the final exception line and discarding the cause chain.
• Adding several Chrome flags at once without a minimal reproduction.
• Increasing locator or page timeouts after the browser process died.
• Running Chrome as root and using --no-sandbox as permanent policy.
• Sharing a user-data directory across parallel sessions.
• Reusing a personal Chrome profile in CI.
• Killing every Chrome process during one test's teardown.
• Ignoring /dev/shm, cgroup memory, disk, and process leaks.
• Assuming the installed ChromeDriver is the executable actually used.
• Collecting only a screenshot, which is unavailable after a crash.
• Retrying a deterministic startup failure until the pipeline passes.
• Restarting a shared Grid node from test code.
• Publishing verbose logs without redacting secrets and URLs.

Conclusion

A selenium chrome not reachable WebDriverException is resolved by finding where communication broke, not by memorizing one flag. Classify startup versus mid-session loss, capture ChromeDriver and platform evidence, prove the environment with a minimal health test, then correct the specific binary, profile, permission, container resource, process, or Grid fault.

Add the prevention checklist to your CI browser image and failure listener. The next occurrence should immediately identify the session, actual versions, worker, last command, and termination evidence, turning a vague WebDriverException into an actionable owner and fix.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Selenium chromedriver version mismatch: Causes and Fixes
• Selenium ElementClickInterceptedException: Causes and Fixes
• Selenium ElementNotInteractableException: Causes and Fixes
• Selenium InvalidElementStateException: Causes and Fixes
• Selenium InvalidSelectorException: Causes and Fixes
• Selenium MoveTargetOutOfBoundsException: Causes and Fixes