[🚀 Feature]: Provide an Option to Disable `purgeDeadNodesService` in Selenium 4 Standalone Mode

[RutvikChandla]

Feature and motivation

Overview
In Selenium 4 Standalone mode, there is a scheduled service (purgeDeadNodesService) that runs every 30 seconds to remove “dead” nodes. This functionality makes sense when operating in a Hub+Node or fully distributed setup, where multiple nodes might come and go. However, in Standalone mode there is effectively only one node, and thus the service can prematurely mark that single node as “dead,” causing brief outages or session failures.

Some environments (for example, those with unexpected clock adjustments or ephemeral deployments) may encounter time discrepancies that can make the node’s health check timestamps appear stale. Since the node is the only Selenium instance in Standalone mode, losing it even briefly causes user-facing failures. An option to disable or configure the purge service would prevent these unnecessary outages.

---

Steps to Reproduce

1. Run Selenium 4 in Standalone mode in an environment where system time may shift unexpectedly (e.g., ephemeral VMs, containers that quickly rebuild, or other situations causing time drifts).
2. Observe that if the time drift is significant, purgeDeadNodesService considers the node’s last health check as outdated.
3. The node is marked as “dead,” leading to “session creation failure” or “node not available” errors until the next heartbeat or restart.

Expected Behavior

• In Standalone mode, the node should not be marked as dead if there is only one node/instance running.
• Users would like a straightforward way to disable or configure the purge service to avoid accidental downtime in time-shifted or short-lived environments.

Actual Behavior

• purgeDeadNodesService runs on a fixed schedule (every 30 seconds) and can mark the node as dead due to stale timestamps in Standalone mode.
• This results in transient failures for tests until the node’s heartbeat is refreshed.

Proposed Solution

• Add a Command-Line Flag or Configuration: e.g. --disable-purge-dead-nodes or a similar parameter that deactivates this service in Standalone mode.
• Make Purge Frequency Configurable: e.g. --purge-dead-nodes-interval=0 (disables), or allow the interval to be increased in Standalone mode to reduce false positives.
• Stand-Alone Specific Behavior: Automatically disable or significantly delay purge checks when running in Standalone mode, since there is only a single node.

Environment

• Selenium version: 4.x (issue observed in multiple 4.x releases)
• Java version: 17 (but likely applies to other versions)
• OS: Any environment subject to ephemeral or time-drift scenarios

Additional Context

• This issue is especially relevant in CI/CD, cloud-based ephemeral environments, or any system where time-based actions might cause false health check results.
• Disabling or adjusting the purge service in Standalone mode would reduce random downtime caused by inaccurate timestamps.

---

Thank you for considering this feature request. Disabling or making the purge service optional in Standalone mode would improve stability for those running Selenium in simple, single-instance setups. If any additional details or logs would be helpful, please let me know and I will provide them.

Usage example

Usage Example
Imagine you have a small team running automated tests in a simple environment—just Selenium Standalone mode on a single VM or container. If the clock on that environment shifts unexpectedly (e.g., due to ephemeral nature of the setup), Selenium’s purgeDeadNodesService may mark the node as “dead” when it sees an outdated last heartbeat. That causes all tests to fail until the next heartbeat arrives or the node is restarted.

By having a flag or configuration option to disable or adjust the purge interval, you eliminate these spurious outages. This benefits not only teams running very basic, single-machine Selenium setups but also larger organizations that create rapid, short-lived test instances. Everyone gains increased stability and faster feedback from their tests without worrying that the node might be killed due to a brief time synchronization issue.

[github-actions]

@RutvikChandla, thank you for creating this issue. We will troubleshoot it as soon as we can.

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[github-actions]

This issue is looking for contributors.

Please comment below or reach out to us through our IRC/Slack/Matrix channels if you are interested.

[joerg1985]

In general i am interrested in making selenium more stable and fix such things.
But in this case i think it might be better to use a different time source, than killing the service.
The logs of the service help to understand the state of the standalone server, as it is still a collection of services internally.

I think the root issue here is the use of System.currentTimeMillis() / Instant / what ever to messure time.
These are based on the real time, so why not using System.nanoTime in this places to avoid these issues?