To Reproduce
-
Run Dokploy on a host with a moderate-to-high number of containers (approx. 20-30+ active containers, including databases and web apps).
-
Monitor host processes (e.g., using htop).
-
Observe regular CPU usage spikes (up to 40-50% on a 6-core setup) from the Dokploy core process (node -r dotenv/config dist/server.mjs) occurring approximately every 20 seconds.
-
Check the Dokploy container logs using docker logs -f .
-
Observe the TimeoutNegativeWarning error firing, followed by dashboard data size warnings.
Current vs. Expected behavior
Current behavior: The background scheduler or polling loop appears to miscalculate the time for the next execution, resulting in a negative timeout (TimeoutNegativeWarning: -19224216.33660932 is a negative number). Node.js falls back to a 1ms timeout, causing the core process to run a heavy task in a continuous, aggressive loop, which spikes the CPU and raises the server's Load Average. Simultaneously, it attempts to fetch large amounts of data for the dashboard (399 kB).
Expected behavior: The internal cron/polling jobs should calculate timeouts correctly, wait the appropriate amount of time between ticks, and gracefully handle fetching metrics from multiple containers without overloading the host CPU.
Provide environment information
OS: Ubuntu Server 22.04.5 LTS (Jammy Jellyfish)
Dokploy Version: v0.29.8
Infrastructure: VPS (6 cores, 32GB RAM) hosting a Docker Swarm/Compose environment with 30+ containers (including Traefik, Postgres, Redis, SeaweedFS, n8n, and custom Node.js/Python apps).
Which area(s) are affected? (Select all that apply)
Docker, Application, Databases, Docker Compose
Are you deploying the applications where Dokploy is installed or on a remote server?
Same server where Dokploy is installed
Additional context
The issue severely degrades the server's I/O and CPU, raising the load average above 10. Here is the exact output from the Dokploy container logs during the spike:
Starting Deployment Worker
(node:53) TimeoutNegativeWarning: -19224216.33660932 is a negative number.
Timeout duration was set to 1.
(Use `node --trace-warnings ...` to show where the warning was created)
Docker Cleanup 6/15/2026, 11:50:00 PM] Running docker cleanup
Access log file does not exist
Warning: data for page "/dashboard/home" is 399 kB which exceeds the threshold of 128 kB, this amount of data can reduce performance.
See more info here: https://nextjs.org/docs/messages/large-page-data
Will you send a PR to fix it?
No
To Reproduce
Run Dokploy on a host with a moderate-to-high number of containers (approx. 20-30+ active containers, including databases and web apps).
Monitor host processes (e.g., using htop).
Observe regular CPU usage spikes (up to 40-50% on a 6-core setup) from the Dokploy core process (node -r dotenv/config dist/server.mjs) occurring approximately every 20 seconds.
Check the Dokploy container logs using docker logs -f .
Observe the TimeoutNegativeWarning error firing, followed by dashboard data size warnings.
Current vs. Expected behavior
Current behavior: The background scheduler or polling loop appears to miscalculate the time for the next execution, resulting in a negative timeout (TimeoutNegativeWarning: -19224216.33660932 is a negative number). Node.js falls back to a 1ms timeout, causing the core process to run a heavy task in a continuous, aggressive loop, which spikes the CPU and raises the server's Load Average. Simultaneously, it attempts to fetch large amounts of data for the dashboard (399 kB).
Expected behavior: The internal cron/polling jobs should calculate timeouts correctly, wait the appropriate amount of time between ticks, and gracefully handle fetching metrics from multiple containers without overloading the host CPU.
Provide environment information
Which area(s) are affected? (Select all that apply)
Docker, Application, Databases, Docker Compose
Are you deploying the applications where Dokploy is installed or on a remote server?
Same server where Dokploy is installed
Additional context
The issue severely degrades the server's I/O and CPU, raising the load average above 10. Here is the exact output from the Dokploy container logs during the spike:
Will you send a PR to fix it?
No