Logs grow forever unless something truncates them. A full disk takes down the database, the web server and the backups at the same time, and it is one of the most common causes of an unexplained outage - see logs that fill the disk.

A rule for your own application

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

The flag that decides whether it works

A process that holds a log file open keeps writing to the ROTATED file. The disk fills exactly as before while the current log stays empty and everything looks fine. Either reload the service in postrotate, as above, or use copytruncate.
copytruncate     # copy the file, then empty the original in place
                 # simpler, and loses the few lines written during the copy

Test it without waiting a day

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/

The journal rotates separately

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

systemd keeps its own logs under its own limits - see reading the system journal.

And watch the disk

df -h
sudo du -xh /var/log /var/www --max-depth=2 2>/dev/null | sort -h | tail -15
Alert at 80% rather than at 95%. Between those two numbers there is time to act; after 95% a large log can close the gap in minutes.