The URL's are vanishing after put into watch using the REST API's

[oms0401]

Describe the bug

Watches that were previously created (URLs we added for monitoring) disappear from the UI as if they were deleted, without us intentionally removing them. The total number of watches drops sharply over time (we maintain on the order of ~1500 URLs; the live list ends up much lower).

This is not asking for help with one website failing to fetch—it is loss of watch rows / URL entries from the application.

Version

0.55.1 (UI). Container image: ghcr.io/dgtlmoon/changedetection.io:latest at deploy time.

How did you install?

Docker Compose on Google Cloud Compute Engine:

• OS: Ubuntu (VM)
• Machine type: e2-medium
• Disk: 50 GB (Docker named volume on this disk for /datastore)
• Approximate scale: ~1552 watches (URLs) we expect to be tracked

Docker Compose (production layout)

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - changedetection

  changedetection:
    image: ghcr.io/dgtlmoon/changedetection.io:latest
    restart: unless-stopped
    expose:
      - "5000"
    volumes:
      - changedetection-data:/datastore
      - ./secrets/proxies.json:/datastore/proxies.json:ro
    environment:
      - PORT=5000
      - PLAYWRIGHT_DRIVER_URL=ws://browser-sockpuppet-chrome:3000
      - MINIMUM_SECONDS_RECHECK_TIME=86400
      - FETCH_WORKERS=4
      - HIDE_REFERER=true
      - BASE_URL=https://<our-public-hostname>
    depends_on:
      browser-sockpuppet-chrome:
        condition: service_started

  browser-sockpuppet-chrome:
    image: dgtlmoon/sockpuppetbrowser:latest
    restart: unless-stopped
    shm_size: "2g"
    cap_add:
      - SYS_ADMIN
    environment:
      - SCREEN_WIDTH=1920
      - SCREEN_HEIGHT=1024
      - SCREEN_DEPTH=16
      - MAX_CONCURRENT_CHROME_PROCESSES=10

volumes:
  changedetection-data:
  caddy_data:
  caddy_config:

[dgtlmoon]

Hey, for now i'll park it in discussions, i've run maybe 3000 concurrent containers with a volume mount and not seen anything get lost...

but its interesting that you're using caddy, I wonder if thats the common denominator

do a find in your watch data dir, how many watch.json is there?

$ find /tmp/data -name watch.json|wc -l
2

$ find /tmp/data -name watch.json
/tmp/data/229553d4-7149-43a6-a3b3-72ea0736e395/watch.json
/tmp/data/bec4b03d-8507-42eb-9641-df2d039ff2d4/watch.json

[dgtlmoon]

What about on startup? show me the logs (attach as .txt), it should say if its finding corrupt watch.json's perhaps

[oms0401]

Do you have mail id or anything i have logs to past 7 days from the docker logs , the github is not allowing me to attach the log file as it is very big for it

[dgtlmoon]

try .zip the the .txt file and attach the zip

[oms0401]

Here it is
cd-logs-7d.zip

[dgtlmoon]

Ahh you're running in windows !?!

are you not telling the whole story? what's going on here exactly?

172.18.0.4 - - [11/May/2026 03:30:53] "GET /C:/Program%20Files/Git/api/v1/systeminfo HTTP/1.1" 404 -
172.18.0.4 - - [11/May/2026 03:30:54] "GET /C:/Program%20Files/Git/api/v1/systeminfo HTTP/1.1" 404 -
172.18.0.4 - - [11/May/2026 03:31:05] "GET /C:/Program%20Files/Git/api/v1/systeminfo HTTP/1.1" 404 -
172.18.0.4 - - [11/May/2026 03:32:03] "GET /C:/Program%20Files/Git/api/v1/systeminfo HTTP/1.1" 404 -
172.18.0.4 - - [11/May/2026 03:32:28] "GET /C:/Program%20Files/Git/api/v1/systeminfo HTTP/1.1" 404 -
172.18.0.4 - - [11/May/2026 03:35:45] "GET /C:/Program%20Files/Git/api/v1/systeminfo HTTP/1.1" 404 -
172.18.0.4 - - [11/May/2026 03:35:54] "GET /C:/Program%20Files/Git/api/v1/systeminfo HTTP/1.1" 404 -

and theres no startup part in these logs...

$ grep -i "watch.json files in" cd-logs-7d.txt 
$ grep -i "Loading watches from individual watch.json files" cd-logs-7d.txt 
$ 

you also didnt show any output of that command above to see how many watch.json files exist..

[oms0401]

changedetection.io is not running on Windows. It runs in Docker on an Ubuntu VM (GCP). I only listed Windows under Desktop because that’s the machine I use for the browser. Sorry that wasn’t explicit; the host OS is Linux.

.
Logs / startup / watch.json greps
The log chunk I shared was only a slice of access lines — that’s why there’s no startup. My local cd-logs-7d.txt had no hits for the exact strings you suggested (watch.json files in / Loading watches from individual watch.json files), probably due to log level, image version, or what was exported.

On-host evidence (today)
I ran this inside the container on the VM:

ls -la /datastore — many <uuid>/ dirs plus changedetection.json, a changedetection-backup-*.zip from 2026-05-09, proxies.json, etc.
find /datastore -name watch.json | wc -l → 496

RIght now the count is 496 urls but in the morning i took the screenshot and it had 894 urls i am adding that screenshot as well