How to Monitor Selenium Tests with Observability

To monitor Selenium tests with observability, capture traces and logs from Selenium Grid, label each session with test and build metadata, then inspect the trace for the failed or slow operation. Grid tracing is enabled by default, but you must choose how to view or export it. Metrics are another useful signal; confirm which metrics and endpoints your deployed Selenium version exposes.

This guide covers Selenium Grid. Local WebDriver tests may need client-side instrumentation or a move to Grid to get the server-side request traces described here. Selenium’s deployment modes include standalone, hub and node, and fully distributed Grid; identify yours first because it determines where server logs and tracing configuration live.

1. Know which signals to collect

Observability combines traces, metrics, and logs. Selenium’s Grid documentation puts it simply: “Observability has three pillars: traces, metrics and logs.” Selenium Grid observability documentation explains its built-in tracing and event logging. OpenTelemetry’s observability primer explains how these signals complement one another.

Signal	What it helps answer	Example in Selenium monitoring
Traces	Where did a request spend time, and which operation failed?	Follow a WebDriver request through Grid components; inspect its spans, attributes, and error events.
Logs	What did a component report at a particular time?	Correlate Grid server or node log entries with a trace ID and timestamp.
Metrics	Is a resource or service showing a broader pattern?	Inspect the metrics your deployment exposes for capacity or service health. Confirm the endpoint and exporter for your version.

A trace represents a request path. Its spans represent timed operations along that path. Trace and span IDs connect related work; span attributes and events add context. An error event can include an exception type, message, and stack trace. A trace helps you narrow the investigation, but it does not prove root cause by itself: inspect the test, client, Grid components, browser, and network evidence.

2. Identify the Grid topology and Selenium version

Record the Selenium Server version used in CI and compare it with the version deployed to Grid.
Write down whether execution is local, standalone, hub and node, fully distributed, or containerized. Note which processes handle routing, sessions, and browser nodes.
Find the server logs and the configuration for the process that runs Selenium Server. In a distributed setup, the relevant evidence may be spread across components.
Check the current Grid observability instructions and the version-specific tracing help before copying commands. Options and exporter setup can change between releases.

Selenium Grid is designed to distribute browser execution across machines and browser and operating-system combinations. Its getting started guide describes deployment and setup. Do not assume every deployment exposes the same metrics or trace backend.

3. Give sessions useful test identity

When many tests run concurrently, session IDs alone are inconvenient identifiers. Set a stable session name such as a suite and test name. Grid supports the se:name metadata capability, which can be shown in the Grid UI or queried through GraphQL. The exact client syntax depends on the language and Selenium binding; use that binding’s capabilities API and confirm the resulting session name in your Grid.

// Java example: add this capability when creating browser options
ChromeOptions options = new ChromeOptions();
options.setCapability("se:name", "checkout / payment declined");
WebDriver driver = new RemoteWebDriver(gridUrl, options);

Carry matching identifiers in your CI and telemetry conventions where available: build, commit, suite, test, browser, browser version, platform, and environment. Keep names stable enough to search and avoid placing secrets or personal data in them. See Selenium’s Grid setup guide for metadata visibility and querying details.

4. Collect and view Grid traces

Grid tracing is instrumented with OpenTelemetry and Selenium says tracing is enabled by default. You still need a route to consume the data. Selenium documents console trace output and Jaeger visualization. The right choice depends on whether you are diagnosing locally or need traces retained and searchable across CI runs.

For a quick local diagnosis, inspect the Grid server output. If trace detail is missing, check the deployed version’s logging and tracing guidance; Selenium’s historical observability article uses FINE logging for console traces.
For visual trace exploration, configure a supported exporter and Jaeger according to the instructions for your Selenium release. The Selenium 4 observability article shows the Jaeger approach and points to the server’s tracing information command.
Check version-specific setup: run java -jar selenium-server-<version>.jar info tracing for the deployed server version where that command is supported, then follow its output and current documentation. Replace the placeholder with the actual jar filename.
Preserve correlation: retain trace IDs, timestamps, session names, and build identifiers alongside CI failure records. Confirm that your exporter and backend preserve the fields you plan to search.

Exporter names, flags, logging configuration, and backend setup are version-sensitive. Do not assume an old command or configuration example applies to a newer Grid. Use the current official observability documentation for the version you run.

5. Triage a failed or slow run

Find the exact run. Search by build and test identity, then confirm browser, platform, session, and timestamp.
Start with the error event. Read the exception type and message, stack trace if present, span status, and operation attributes. Follow the trace and span IDs to related operations.
Locate time spent. For slow tests, compare span durations and identify where time accumulates: client request, Grid routing, browser operation, or another observed component.
Compare related executions. Compare the same test across runs, nodes, browsers, browser versions, and platforms. Look for a repeated signature or a component-specific delay.
Correlate logs and available metrics. Use timestamps and trace IDs to inspect Grid and node logs. Check the metrics your deployment actually exports for signs of broader resource or service issues.
Inspect the environment and test. Review client-side behavior, network conditions, browser state, Grid capacity, and the test’s waits and assertions. Treat a suspected transient failure as a lead; repeated execution and context are needed to assess flakiness.

Selenium’s discussion of observability describes latency and errors as clues for investigating client and server behavior. Telemetry narrows the search; it cannot by itself distinguish every infrastructure, network, browser, or test-code cause.

6. Connect client-side and server-side evidence

Grid traces show server-side request paths. A failure can also originate in the test client, so connect client logs and timing with the same test, build, and session context. Selenium’s 2021 article describes full-stack tracing for the Java client and server; availability and setup depend on the client language and release. Check current binding documentation before assuming equivalent tracing support in another language.

7. Choose a trace viewing approach

Approach	Useful for	Consider
Grid console output	Short local investigations and checking that traces are being emitted.	Log verbosity, output volume, and whether CI retains the logs.
Jaeger visualization	Following spans and comparing operation timing visually.	Version-specific exporter configuration, retention, access control, and backend operations.
Existing observability backend	Teams that already search telemetry across CI and services.	Verify exporter compatibility, trace fields, retention, and any metrics support for your Grid version.

OpenTelemetry describes a broad ecosystem: its documentation reports support from more than 90 observability vendors, as of its August 29, 2025 update. That figure describes framework support, not Selenium adoption or a guarantee that a particular backend works with your Grid configuration. OpenTelemetry documentation.

8. Selenium monitoring troubleshooting

Symptom	Likely cause	What to do
No traces appear in the viewer	Tracing may be enabled in Grid but no exporter or viewer is configured, or the backend is not receiving data.	Check server output, version-specific tracing help, exporter configuration, and backend connectivity.
Console has little trace detail	Logging verbosity may be too low, or the relevant component’s output is not being collected.	Follow the deployed version’s logging instructions and collect logs from the component handling the request.
Trace is hard to match to a test	Sessions lack stable names or CI metadata is not retained with trace identifiers.	Set `se:name` through the client capabilities API and carry build, suite, and test identifiers through CI records.
Trace exists, but the failure is unclear	Server-side spans alone may not show client state, browser behavior, or network conditions.	Correlate client logs, Grid and node logs, timestamps, browser details, and the test’s assertions and waits.
Trace command or option is rejected	Example may target a different Selenium release or deployment mode.	Check `java -jar selenium-server-<version>.jar info tracing` where supported and consult the matching official docs.
One run is slow, but others are normal	Could be a transient resource, network, node, or browser condition; one trace does not establish a recurring cause.	Compare more runs across nodes and browser versions and inspect correlated logs and metrics.
Metrics expected from a guide are absent	That endpoint or metric may not be exposed by the specific deployment or version.	Verify the current Grid configuration and metrics support; do not infer availability from tracing documentation alone.

9. Performance, reliability, and cost considerations

Performance: telemetry collection and export add work and produce data. Start with the diagnostic detail you need, then tune logging, sampling, and retention according to the current Grid and backend documentation. No universal overhead figure applies across deployment sizes and configurations.
Reliability: decide what happens when an exporter or backend is unavailable. Keep enough CI logs and test metadata to diagnose runs during an observability outage. Trace absence should not be mistaken for proof that a test did not execute.
Retention and access: traces and logs can reveal URLs, exception details, and environment context. Set retention and access policies appropriate to your data and avoid adding credentials or sensitive values to test names or telemetry attributes.
Cost: no backend pricing or provider terms are established here. Estimate from expected test volume, trace and log volume, retention, and concurrency; verify current backend plans and limits directly.

10. Self-managed Grid or hosted browser execution

Self-managed Grid gives your team responsibility for deployment, capacity, upgrades, and telemetry configuration. Hosted browser execution can shift some infrastructure operations, but compare actual offerings before deciding. Evaluate browser and operating-system coverage, version control, parallel session capacity, trace and log export, screenshots or video, retention, CI integration, access controls, usage limits, and total cost at expected concurrency. This guide does not verify any specific hosted provider’s features or terms.

Or skip the browser setup

For a screenshot artifact of a page involved in a failing test, ScreenshotNeo is a website screenshot API and MCP server. It complements Selenium observability: it can capture the page as an image or PDF, while Grid traces help diagnose the test request path. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners are accepted and removed before capture; 60+ known consent platforms, newsletter popups, and chat widgets are removed. Each step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers report the page verdict and billing status.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots.

FAQ

Is Selenium Grid tracing enabled by default?

Selenium’s Grid observability documentation says server tracing is enabled by default. You still need a supported way to export or view the traces.

Does a trace prove that a test is flaky?

No. A trace records evidence from an execution. Compare repeated runs and their environments before drawing conclusions about intermittent failures.

Can I monitor tests that do not use Grid?

This workflow focuses on Grid server traces. For local execution, use client-side logs and instrumentation supported by your binding, or run through Grid when server-side request tracing is needed.

Where can I find the right tracing command?

Use the official Grid observability docs for your deployed release. The server’s info tracing command can also show version-specific guidance where supported.