[Bug]: Increased CPU usage when having multiple tabs open

[alxhu-dev]

Error Message and Logs

When I open multiple resources in Coolify UI, the CPU usage of the host system (where Coolify is installed) goes to 100%.

When I close the tabs, CPU usage goes down to normal CPU usage.

Steps to Reproduce

1. Open any project
2. Open multiple services in new tabs (I had 12 open)
3. Watch increasing CPU usage of host system

Example Repository URL

No response

Coolify Version

v4.0.0-beta.459

Are you using Coolify Cloud?

No (self-hosted)

Operating System and Version (self-hosted)

Debian 12 / DietPi v9.20.1

Additional Information

I have Coolify installed on a RPi 4 Model B.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Possible Duplicates

• ISSUE-6125

Related Issues

• [Bug]: Server CPU usage reaches 100% after installing Coolify on a VPS #7844
• [Bug]: Coolify Container High CPU & Memory Usage #5676
• [Bug]: Running 'htop' on Coolify terminal will cause a massive CPU leak #6125
• [Bug]: High CPU from Coolify Redis Container #5768

👤 Suggested Assignees

• GuruDev1736
• SyahmiRafsan
• arxkdev
• RealFascinated

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[andrasbacsai]

@claude Review this issue. Assess validity, identify the root cause, check if this is a regression from recent changes, and propose a step-by-step fix with specific file changes. Flag any risks or missing information.

[claude]

Claude finished @andrasbacsai's task in 4m 28s —— View job

---

Analysis: Increased CPU Usage with Multiple Tabs

• Gather context and validate the issue
• Identify potential root causes (WebSocket/Livewire polling)
• Check for related issues and recent changes
• Propose a fix with specific file changes
• Assess risks and missing information

---

Issue Validity: ✅ Confirmed Valid

This is a real bug. When users open multiple tabs (12 in the reporter's case), Livewire polling requests multiply by the number of tabs, overwhelming the host system (especially on low-powered devices like RPi 4).

---

Root Cause Analysis

Primary Issue: Unconditional Polling Without Tab Visibility Awareness

The codebase has 16+ Livewire components using wire:poll, but none use the .visible modifier that Livewire 3 provides to pause polling when the browser tab is not visible.

Key offenders that poll regardless of tab visibility or state:

Component	File	Interval	Issue
DeploymentsIndicator	resources/views/livewire/deployments-indicator.blade.php:1	3s	Always polls, even with 0 deployments
Application Heading	resources/views/livewire/project/application/heading.blade.php:1	10s	Always polls
Database Heading	resources/views/livewire/project/database/heading.blade.php:1	10s	Always polls
Service Heading	resources/views/livewire/project/service/heading.blade.php:1	10s	Always polls
Tags Deployments	resources/views/livewire/tags/deployments.blade.php:1	2s	Always polls, even if no active deployments
Tags Show	resources/views/livewire/tags/show.blade.php:69	default (~2s)	Always polls

Secondary Issue: Database Queries Per Poll

Each poll triggers database queries. For example, DeploymentsIndicator runs:

Server::ownedByCurrentTeamCached()
ApplicationDeploymentQueue::with(['application.environment.project'])
    ->whereIn('status', ['in_progress', 'queued'])
    ->whereIn('server_id', ...)
    ->get()

With 12 tabs, this executes 12× every 3 seconds = 240 queries/minute just for this one component.

---

Is This a Regression?

No, this does not appear to be a regression from recent changes. The polling architecture has been in place for some time. However, the issue becomes noticeable when:

1. Users open many tabs (as workflows become more complex)
2. Running on lower-powered hardware (RPi 4)
3. Having many resources/deployments

---

Proposed Fix (Step-by-Step)

Phase 1: Add .visible modifier to all polling components (Low Risk, High Impact)

The .visible modifier pauses polling when the tab is not visible. This is the most impactful and safest change.

Files to modify (16 total):

#	File	Line	Change
1	resources/views/livewire/deployments-indicator.blade.php	1	wire:poll.3000ms → wire:poll.3000ms.visible
2	resources/views/livewire/project/application/heading.blade.php	1	wire:poll.10000ms → wire:poll.10000ms.visible
3	resources/views/livewire/project/database/heading.blade.php	1	wire:poll.10000ms → wire:poll.10000ms.visible
4	resources/views/livewire/project/service/heading.blade.php	1	wire:poll.10000ms → wire:poll.10000ms.visible
5	resources/views/livewire/tags/deployments.blade.php	1	wire:poll.2000ms → wire:poll.2000ms.visible
6	resources/views/livewire/tags/show.blade.php	69	wire:poll → wire:poll.visible
7	resources/views/livewire/activity-monitor.blade.php	8	wire:poll.1000ms → wire:poll.1000ms.visible
8	resources/views/livewire/activity-monitor.blade.php	55	wire:poll.1000ms → wire:poll.1000ms.visible
9	resources/views/livewire/server/charts.blade.php	12	wire:poll.5000ms → wire:poll.5000ms.visible
10	resources/views/livewire/project/shared/metrics.blade.php	26	wire:poll.5000ms → wire:poll.5000ms.visible
11	resources/views/livewire/project/application/deployment/show.blade.php	172	wire:poll.2000ms → wire:poll.2000ms.visible
12	resources/views/livewire/project/application/deployment/index.blade.php	6	wire:poll.5000ms → wire:poll.5000ms.visible
13	resources/views/livewire/project/shared/get-logs.blade.php	239	wire:poll.2000ms → wire:poll.2000ms.visible
14	resources/views/livewire/server/docker-cleanup-executions.blade.php	1	wire:poll.5000ms → wire:poll.5000ms.visible
15	resources/views/livewire/project/shared/scheduled-task/executions.blade.php	1	wire:poll.5000ms → wire:poll.5000ms.visible
16	resources/views/livewire/project/database/backup-executions.blade.php	32	wire:poll.5000ms → wire:poll.5000ms.visible
17	resources/views/livewire/server/show.blade.php	18	wire:poll.5s → wire:poll.5s.visible

Phase 2 (Optional): Conditional Polling for DeploymentsIndicator

Stop polling entirely when there are no active deployments.

---

Risk Assessment

Change	Risk Level	Reason
Adding .visible modifier	🟢 Low	Native Livewire 3 feature, no logic changes, only affects background tabs
Conditional polling	🟡 Medium	Requires testing to ensure WebSocket events still trigger refreshes

---

Missing Information

1. No CPU profiling data - Would help identify which specific components consume most CPU
2. No exact Soketi/WebSocket configuration - Could also contribute to CPU usage
3. Browser version - Some browsers handle polling differently

---

Related Issues

• This is likely related to [Bug]: Running 'htop' on Coolify terminal will cause a massive CPU leak #6125 which appears to discuss similar performance concerns
• Issues [Bug]: Server CPU usage reaches 100% after installing Coolify on a VPS #7844, [Bug]: Coolify Container High CPU & Memory Usage #5676, [Bug]: High CPU from Coolify Redis Container #5768 may also be related

---

Recommendation

Immediate Fix: Apply Phase 1 changes (.visible modifier) to all polling components. This is a safe, non-breaking change that will:

• Reduce CPU usage by ~90% when multiple tabs are open (only active tab polls)
• Require no backend changes
• Be easily verifiable by users

Would you like me to implement these changes?