Introduction

The first thing to check is which Log4j generation you are actually using. Monthly rollover and automatic deletion of files older than 30 days is a much cleaner fit for Log4j 2 than for old Log4j 1 appenders, where retention often needs to be handled externally.

Rotation and Retention Are Different

These two requirements are related but separate:

• rotation decides when a new log file starts
• retention decides when old log files are deleted

Many questions mix them together, which leads to confusing configurations.

If your requirement is "roll monthly and keep only 30 days," you need both a time-based rollover policy and an age-based deletion policy.

Log4j 1 Limitation

Classic Log4j 1 RollingFileAppender is mainly size-based. DailyRollingFileAppender adds time-based rollover, but built-in age-based retention management is limited and not a strong fit for "delete anything older than 30 days."

So if you are truly on Log4j 1, the honest answer is often:

1. let Log4j handle rollover
2. let the operating system or scheduler handle cleanup

That could mean logrotate, a cron job, or another external housekeeping process.

Native Log4j 2 Solution

If you can use Log4j 2, RollingFile plus a delete action expresses the requirement directly.

1<Appenders>
2  <RollingFile name="AppLog"
3               fileName="logs/app.log"
4               filePattern="logs/$${date:yyyy-MM}/app-%d{yyyy-MM}-%i.log.gz">
5    <PatternLayout pattern="%d %-5p %c - %m%n" />
6    <Policies>
7      <TimeBasedTriggeringPolicy interval="1" modulate="true" />
8    </Policies>
9    <DefaultRolloverStrategy>
10      <Delete basePath="logs" maxDepth="2">
11        <IfLastModified age="30d" />
12      </Delete>
13    </DefaultRolloverStrategy>
14  </RollingFile>
15</Appenders>

This gives you:

• time-based rollover
• archived file naming
• automatic deletion of files older than 30 days

That is why Log4j 2 is the cleaner answer when retention rules matter.

Monthly Rollover Details

The monthly schedule is primarily expressed through the time-based policy and the date pattern in the archive path or filename.

Compression is usually a good idea because monthly files can get large. Keeping the active file stable, while archiving rolled files with time-stamped names, is also easier to operate and monitor.

If You Must Stay on Log4j 1

If migration is not possible, split the problem:

• use Log4j for rolling
• use the operating system for retention

A Linux logrotate strategy often works better than trying to force unsupported retention semantics into a Log4j 1 appender configuration.

That approach is less glamorous, but it is reliable and honest about what the older framework can and cannot do.

Test the Policy Before Trusting It

Log rotation bugs are easy to miss because they only appear:

• at month boundaries
• when the archive path changes
• when deletion should finally happen

That means you should test rollover behavior in a controlled environment before assuming the production configuration is correct.

At minimum, confirm:

• files roll on the expected schedule
• archive names match what you planned
• old files are actually deleted after the age threshold

Common Pitfalls

Treating rollover schedule and retention age as if they were one setting is the first mistake.

Expecting Log4j 1 RollingFileAppender to provide strong age-based cleanup is usually unrealistic.

Copying a Log4j 2 delete policy into a Log4j 1 configuration does not work because the feature sets are different.

Not testing month-boundary behavior can leave you with a configuration that looks correct on paper but fails in production.

Summary

• Monthly rollover and 30-day retention are separate logging requirements.
• Older Log4j 1 appenders are weak at native age-based retention.
• Log4j 2 RollingFile is the cleaner built-in answer for rollover plus delete-by-age behavior.
• If you must stay on Log4j 1, use external retention cleanup such as logrotate.
• Always test rotation and deletion behavior instead of trusting the config by inspection alone.