What log retention and alerting gaps exist in cPanel Git deployment logging for production diagnostics?

Context

cPanel v100+ stores Git deployment logs in each repository's .cpanel/logs/deploy.log and surfaces the last 100 lines in the "Deployment Logs" UI. The interface marks failed runs with a red status but does not rotate logs, enforce quotas, or emit failure notifications by default.

Problem

Without built-in log rotation, the log file grows indefinitely and can consume significant disk space on busy repositories. Administrators must implement custom logrotate rules or cron-based parsing to detect failures, because cPanel does not send email or push alerts when a deployment exits non-zero. The UI truncation to 100 lines also means older failure context is only available by reading the raw file directly.

Open questions

1. Which log rotation strategy (size-based, time-based, or count-based) aligns with cPanel's account quota system without interfering with the Git Version Control interface?
2. Does a lightweight cron job that tails deploy.log for non-zero exit markers and calls the cPanel API provide reliable failure detection, or are there race conditions with concurrent deployments?
3. What is the recommended maximum retention period before log growth impacts backup windows or inode limits on typical shared-hosting filesystems?