Watch Checks run into error Timeout "BrowserType.connect_over_cdp: Timeout 60000ms exceeded. Call log: <ws connecting> ws://playwright-chrome:3000/ "

[FurkanVG]

Describe the bug
When i reboot my host system, and then my docker compose for changedetection starts up, some checks are stuck in a specific error:

"Exception: BrowserType.connect_over_cdp: Timeout 60000ms exceeded. Call log: ws://playwright-chrome:3000/ "

If i have lets say 10 Checks, it is a random amount always after reboot. It can be 3, 5 or even 9 out of 10 being in the error above

Version
v0.47.06

How did you install?
docker compose:

version: '3.2'

services:
  changedetection:
    image: ghcr.io/dgtlmoon/changedetection.io:dev
    container_name: changedetection
    hostname: changedetection
    volumes:
      - ChangeDetection:/datastore
    ports:
      - "5000:5000"
    environment:
      - LOGGER_LEVEL=TRACE
      - PLAYWRIGHT_DRIVER_URL=ws://playwright-chrome:3000
      - BASE_URL=https://change.furrkan.de
    restart: unless-stopped
    depends_on:
      playwright-chrome:
        condition: service_started

  playwright-chrome:
    hostname: playwright-chrome
    image: dgtlmoon/sockpuppetbrowser:latest
    cap_add:
      - SYS_ADMIN
    restart: unless-stopped
    environment:
      - SCREEN_WIDTH=1920
      - SCREEN_HEIGHT=1024
      - SCREEN_DEPTH=16
      - MAX_CONCURRENT_CHROME_PROCESSES=10

volumes:
  ChangeDetection:
    external: true

To Reproduce

I dont think this is the case for everybody, it may be something with my host system. But like i said, if i reboot my host, and then the docker container start, it is in the error. If i manully restart the docker containers AFTER they were running already after reboot, then the error dont come back anymore.

Expected behavior
Checks should not run into error, even if i reboot my host. Im doing this same procedure for months where i reboot the host weekly and i had never the issue.

Desktop (please complete the following information):

• OS: Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-49-generic x86_64)
• Browser Playwright-Chrome (see Docker Compose)

Additional context
I can provide any logs if told wherre to get them.

Thanks!

[dgtlmoon]

Hmm the config looks OK, and if your 'recheck' them all, does it work again?

[FurkanVG]

Hi,
Rechecking all doesn't change anything, since it tries to check them anyway every 5mins.

Clearing the erroe and rechecking also doesnt help

[searchjaunt]

I'm facing the same behavior regularly lately. Each time it'll be a surprise how many of the watches will end up with this error.

[mvantschip]

I am also facing the same problem. Has anyone perhaps found a solution?

[Orcamm]

Also got the same issue on several of my tracking links. Any one know what's going on?

[searchjaunt]

With the latest update, it's happening a lot. Besides that error, I'm also getting Exception: Page.content: Target page, context or browser has been closed

[searchjaunt]

Not sure what the relation is, but the CPU demand is peaking when these errors happen

As you can see, when the CPU is otherwise not overloaded with other processes

[bryanwagg]

Just thought I would chime in herewith my experience of this issue as it turned out to be simple fix for myself when I was running into this same issue when using the new sockpuppet service. (previously was using selenium web driver, but proxy was not working anymore).

For Context I use docker compose on my Synology DS220+ Nas, and I think by default the synology firewall was blocking connectivity between containers by default (or possibly only the sockpuppet container reaching the internet?). I briefly remember having to set up a bridge (forgive me if details are lacking, it was over 2 years) and having to explicitly allow incoming and outgoing requests over a certain range (I use 172.17.0.0 - 172.17.0.10).

Having recently upgraded the changedetection.io version to a more recent one (again, cant give specifics as over 2 years old). My docker-compose.yaml was a little out of date, meaning the default hostnames were first of all incorrect compared to current version, networks misconfigured, and due to the mentioned firewall issue hostnames would not resolve resulting in me having to use container IP’s In the webdriver variables.

I could have dug a little deeper for the exact cause and also havent tested whether or not hostnames work now instead of specific container ips for PLAYWRIGHT_DRIVER_URL= but my set up is now working and would prefer not to mess around more.

TLDR:
Persistent Timeout issue mentioned by OP is more than likely down to inter - container connectivity (or possibly upstream from sockpuppet -> internet timeout). Would highly recommend debugging your containers by attaching a terminal session and trying to ping from one to the other and then to the outside world.