What Is Log Rotation?
Log rotation is the process of closing an active log file, archiving it, and starting a new file under the original name. It runs on the system that writes the log. It stops one file from growing until it fills the disk.
Rotation also keeps individual files small enough to open, search, and analyze quickly. A multi-gigabyte log is slow to read even when the disk still has room on it.
Treat it as housekeeping that runs on the source host. A log file nobody manages grows until the disk is full, and the service writing to it stops there.
Debug logging left switched on after a release is the usual culprit. It can fill a disk in days on a host that looked comfortable for months.
How Does Log Rotation Work?
A rotation runs as four steps, and the whole sequence takes seconds.
Trigger: a limit you configured is reached, whether that is a maximum file size, an age, or a count of retained files.
Rename: the active file is renamed or moved to an archive name, keeping every event already written to it.
Recreation: a new empty file appears under the original name, so your application carries on writing without pausing and without dropping lines.
Compression: the rotated file is usually compressed on the way out, which is where most of the disk saving comes from.
Renaming is what keeps the order readable. Numbered suffixes run app.log.1, app.log.2 and upward, where the higher number is the older file. Timestamp suffixes such as app_20260814.log put the date in the name instead.
A file ending in .gz has already been through the compression step. Compressed rotated logs are the norm on Linux hosts.
What Triggers a Log Rotation?
Three triggers cover almost every setup you will meet. Most hosts run more than one of them at a time.
Size: the file rotates once it crosses a threshold you choose, say 100 MB. Sources whose volume swings through the day suit this one, because the trigger follows the traffic rather than the clock.
Time: rotation happens on a schedule, usually nightly or weekly. Each file then covers a period you can reason about.
Count: the host keeps a fixed number of old files and drops the oldest when a new one arrives. Disk use stays capped whatever the volume does.
Which Tools Handle Log Rotation?
Either the operating system handles rotation or the application does. Knowing which one owns a given file is the first thing to establish.
logrotate: the standard utility on Linux. Config files under /etc/logrotate.d hold the rules. You set the trigger, the number of files to keep, and whether to compress.
Cron jobs and systemd timers: logrotate does not watch your files continuously. A scheduled job wakes it, usually once a day, and that schedule decides how often the check happens at all.
newsyslog: the macOS and BSD equivalent, reading its rules from newsyslog.conf.
LogRotateWin: a Windows port of logrotate. Hosts that need matching behavior across a mixed estate tend to run it.
Built-in application rotators: web servers, databases, and logging libraries frequently rotate their own files. The setting then lives in the application config rather than the operating system, which is where it gets missed.
On a Linux host, the syslog daemon usually owns whatever sits under /var/log. Anything writing outside that directory tends to look after itself.
We check both places before changing anything. A host can otherwise end up with the operating system and the application rotating the same file.
That produces gaps nobody planned for. Those gaps surface only when you go hunting for an event that was never written.
How Often Should Logs Be Rotated?
Write volume sets the frequency, not a standard schedule. A slow-growing file can rotate weekly. A file under heavy write load may need rotating more than once a day.
Nightly rotation is the common default on servers under steady load. Each file stays small enough to open and grep directly on the host. That matters when you are reading it at two in the morning.
We size the trigger to the file rather than to the calendar. A nightly job on a busy proxy still leaves you a file too big to read comfortably.
Check the retained count alongside the frequency, because the two multiply. Rotating hourly while keeping 24 files leaves you one day of history rather than the month you might have assumed.
What Happens to Rotated Log Files?
Four destinations are available, and most teams pick a different one per log type.
Deletion: the oldest file goes once the retained count is reached. It is the cheapest option to run, and there is no undo.
Compression on the host: old files stay local, in compressed form. Keeping them close helps when you are troubleshooting something that started last week. It also costs a fraction of the uncompressed disk.
Archival: files move off the host to cheaper storage, where they sit for the long term and get read back rarely.
Forwarding to a central platform: events ship as they are written. The local file turns into a buffer rather than the record you depend on. That changes what rotation is even for.
Once log collection holds your events centrally, local files can rotate hard. The copy that matters lives elsewhere by then, and a log forwarder is the usual way to get it there.
Wherever they end up, rotated files still need protecting. They carry the same sensitive values the live file did. Access control and integrity checks belong on the archive as much as on the active log.
How Is Log Rotation Different from Log Retention?
Teams often treat rotation and retention as one control. They are two, and they sit in different places. Rotation governs the files on the host that produced them. Log retention governs how long the central copy stays searchable.
What sets them off differs as well. File size, age, or count fires a rotation. Retention instead runs on a period attached to a storage tier inside an observability pipeline. Log indexing is what defines that tier.
The failure modes are different too. A failed rotation fills a disk and takes the service down with it. Retention fails more quietly, and you find out on the day somebody asks for evidence you no longer hold.
In most environments both are running at once. A server may rotate its own files hourly. The platform holding the forwarded copy keeps them for a year. Neither setting knows the other exists.
Rotation protects the host and retention protects the record. Set them separately, and confirm the second is in place before you make the first more aggressive.
Explore More IT Terms
Browse our comprehensive IT glossary to learn more about technology terminology.