I log crescono all'infinito finché qualcosa non li taglia. Un disco pieno butta giù insieme il database, il server web e i backup, ed è una delle cause più frequenti di un'interruzione inspiegabile — vedi I log che riempiono il disco.

Una regola per la tua applicazione

# /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
}

L'opzione che decide se funziona

Un processo che tiene aperto un file di log continua a scrivere sul file GIÀ RUOTATO. Il disco si riempie esattamente come prima mentre il log corrente resta vuoto e sembra tutto a posto. O ricarichi il servizio in postrotate, come sopra, oppure usi copytruncate.
copytruncate     # copy the file, then empty the original in place
                 # simpler, and loses the few lines written during the copy

Provalo senza aspettare un giorno

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/

Il journal ruota per conto suo

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

systemd tiene i propri log sotto i propri limiti — vedi Leggere il journal di sistema.

E tieni d'occhio il disco

df -h
sudo du -xh /var/log /var/www --max-depth=2 2>/dev/null | sort -h | tail -15
Fai scattare l'avviso all'80% invece che al 95%. Fra quei due numeri c'è tempo per intervenire; superato il 95%, un log grosso può colmare la differenza in pochi minuti.