coolify/app/Actions
Andras Bacsai d2d9c1b2bc debug: add comprehensive status change logging
Added detailed debug logging to all status update paths to help
diagnose why "unhealthy" status appears in the UI.

## Logging Added

### 1. PushServerUpdateJob (Sentinel updates)
**Location**: Lines 303-315
**Logs**: Status changes from Sentinel push updates
**Data tracked**:
- Old vs new status
- Container statuses that led to aggregation
- Status flags (hasRunning, hasUnhealthy, hasUnknown)

### 2. GetContainersStatus (SSH updates)
**Location**: Lines 441-449, 346-354, 358-365
**Logs**: Status changes from SSH-based checks
**Scenarios**:
- Normal status aggregation
- Recently restarted containers (kept as degraded)
- Applications not running (set to exited)
**Data tracked**:
- Old vs new status
- Container statuses
- Restart count and timing
- Whether containers exist

### 3. Application Model Status Accessor
**Location**: Lines 706-712, 726-732
**Logs**: When status is set without explicit health information
**Issue**: Highlights cases where health defaults to "unhealthy"
**Data tracked**:
- Raw value passed to setter
- Final result after default applied

## How to Use

### Enable Debug Logging
Edit `.env` or `config/logging.php` to set log level to debug:
```
LOG_LEVEL=debug
```

### Monitor Logs
```bash
tail -f storage/logs/laravel.log | grep STATUS-DEBUG
```

### Log Format
All logs use `[STATUS-DEBUG]` prefix for easy filtering:
```
[2025-11-19 13:00:00] local.DEBUG: [STATUS-DEBUG] Sentinel status change
{
  "source": "PushServerUpdateJob",
  "app_id": 123,
  "app_name": "my-app",
  "old_status": "running:unknown",
  "new_status": "running:healthy",
  "container_statuses": [...],
  "flags": {...}
}
```

## What to Look For

1. **Default to unhealthy**: Check Application model accessor logs
2. **Status flipping**: Compare timestamps between Sentinel and SSH updates
3. **Incorrect aggregation**: Check flags and container_statuses
4. **Stale database values**: Check if old_status persists across multiple logs

## Next Steps

After gathering logs, we can:
1. Identify the exact source of "unhealthy" status
2. Determine if it's a default issue, aggregation bug, or timing problem
3. Apply targeted fix based on evidence

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-19 13:52:08 +01:00
..
Application fix(application): increase docker stop timeout from 10 to 30 seconds for better application shutdown handling 2025-09-29 12:16:13 +02:00
CoolifyTask refactor(proxy-status): refactored how the proxy status is handled on the UI and on the backend 2025-06-06 14:47:54 +02:00
Database fix: remove debugging output from StartPostgresql command handling 2025-11-05 09:10:15 +01:00
Docker debug: add comprehensive status change logging 2025-11-19 13:52:08 +01:00
Fortify fix(user): ensure email attributes are stored in lowercase for consistency and prevent case-related issues 2025-09-05 17:44:34 +02:00
Proxy fix(proxy): prevent "container name already in use" error during proxy restart 2025-11-14 11:35:22 +01:00
Server fix: remove PullHelperImageJob and mass server scheduling 2025-11-14 11:31:08 +01:00
Service refactor: improve command handling and ensure correct working directory for Docker operations 2025-11-10 14:40:03 +01:00
Shared fix: preserve unknown health state and handle edge case container states 2025-11-19 13:19:25 +01:00
Stripe Changes auto-committed by Conductor 2025-10-16 17:13:47 +02:00
User Changes auto-committed by Conductor 2025-10-16 17:13:47 +02:00