Identify all log destinations, including framework files, web-server logs, worker output and external monitoring. Determine who owns their rotation and access controls.

1. Remove unnecessary sensitive fields from logging before deciding how long to keep the records. Avoid reusable credentials and full private payloads.

2. Set rotation by suitable size or time through the platform or logging service. Choose a retained amount based on the application’s needs and applicable requirements.

3. Confirm the application can continue logging after rotation and that old files have appropriate permissions. Account for multiple workers writing concurrently.

4. Monitor disk and inode usage and provide a controlled way to preserve relevant logs during an incident before routine deletion.

5. Test rotation and retrieval of an older record. Document the retention policy and where support should look for each type of error.

Suppose one application log is intended to rotate around 10 MiB and retain seven archived files. Budget roughly 80 MiB for the active file plus those archives before compression, then allow headroom for rotation timing and unusually large entries. These are illustrative settings, not a required retention policy.

A periodic rotation job can allow the active log to grow beyond its threshold before the next run. Multiple processes or separate worker logs can multiply the total. Verify the actual logging handler and rotation owner rather than treating one size value as a hard account-wide cap.

After a controlled rotation test, write a new application event and locate both that event and an older retained one. Confirm their permissions and ensure neither the active nor archived log is downloadable from the website.

Confirm current logs keep receiving entries after rotation and retained files can be read by authorised staff. Check that compressed or archived logs do not remain publicly downloadable.

A deleted file can still consume space while a process holds it open. Use the platform’s supported rotation or process-reopen procedure rather than repeatedly deleting active logs.

• Setting up a production Flask error log
• Recording useful API error details without secrets
• Keeping temporary uploads from filling application storage
• Choosing a database connection pool size

• OWASP logging
• Python logging handlers