Los registros crecen sin fin mientras nada los recorte. Un disco lleno tumba a la vez la base de datos, el servidor web y las copias de seguridad, y es una de las causas más habituales de una caída inexplicada: consulta Registros que llenan el disco.

Una regla para tu propia aplicación

# /etc/logrotate.d/site
/var/www/site/storage/logs/*.log {
    daily
    rotate 14
    size 100M
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    sharedscripts
    postrotate
        systemctl reload php8.3-fpm > /dev/null 2>&1 || true
    endscript
}

La opción que decide si funciona

Un proceso que mantiene abierto un archivo de registro sigue escribiendo en el archivo YA ROTADO. El disco se llena igual que antes mientras el registro actual queda vacío y todo parece correcto. O recargas el servicio en postrotate, como arriba, o usas copytruncate.
copytruncate     # copy the file, then empty the original in place
                 # simpler, and loses the few lines written during the copy

Pruébalo sin esperar un día

sudo logrotate -d /etc/logrotate.d/site      # dry run, prints what it would do
sudo logrotate -f /etc/logrotate.d/site      # force it now
ls -la /var/www/site/storage/logs/

El journal rota por su cuenta

journalctl --disk-usage
sudo journalctl --vacuum-size=500M

systemd guarda sus propios registros bajo sus propios límites: consulta Leer el journal del sistema.

Y vigila el disco

df -h
sudo du -xh /var/log /var/www --max-depth=2 2>/dev/null | sort -h | tail -15
Avisa al 80 %, no al 95 %. Entre esos dos números hay tiempo para actuar; pasado el 95 %, un registro grande puede cerrar la diferencia en minutos.