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\n/var/www/site/storage/logs/*.log {\n    daily\n    rotate 14\n    size 100M\n    compress\n    delaycompress\n    missingok\n    notifempty\n    create 0640 www-data www-data\n    sharedscripts\n    postrotate\n        systemctl reload php8.3-fpm > /dev/null 2>&1 || true\n    endscript\n}

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\n                 # 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\nsudo logrotate -f /etc/logrotate.d/site      # force it now\nls -la /var/www/site/storage/logs/

The journal rotates separately

journalctl --disk-usage\nsudo journalctl --vacuum-size=500M

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

And watch the disk

df -h\nsudo 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.