You probably have a dedicated CI runner account for your Ansible plays. Over months of automated runs, the home directory of that user starts to look like a hoarding situation. Between the .ansible directory growing unchecked and stray tmp files left by failed plays, you are eventually going to hit disk quotas or inode limits. It is a quiet form of rot that only bites you when you are already dealing with a failed deployment.

Why the cleanup jobs usually fail

Most engineers try to handle this by manually deleting folders, but that is a race against time. If a job is running while your cron job triggers, you might delete a cache file that an active play needs. The right approach is to handle state locally within the run itself or use a dedicated scratch directory that you wipe on a schedule, rather than treating the runner home like a permanent data store.

find /home/ansible/.ansible/tmp -type f -mtime +7 -delete

• Force Ansible to use a custom temp directory via ANSIBLE_LOCAL_TMP in your env config
• Set a short TTL for your CI runner’s shell history to keep the shell logs from bloating
• Use a tmpfs mount for the cache directory to ensure everything vanishes on reboot

If you are running Ansible in a containerized CI runner, this is easier to manage. Just point the home directory to an ephemeral volume and let the orchestrator handle the teardown. But if you are stuck with bare metal or persistent VMs, put this cleanup script into a systemd timer rather than a standard cron job. It gives you better logging when it fails, and you can add a condition to check if the runner is currently idle before hitting the delete key.