Logging New Added 19 September 2026

log4j2: ERROR StatusLogger No Log4j 2 configuration file found

Log4j 2 could not find log4j2.xml on the classpath and fell back to logging errors only to the console, which is why the application starts but INFO and DEBUG never appear. In a packaged jar the file is usually present in the source tree and missing from the artefact, not absent from the repository.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix

# Is the file actually inside the jar
jar tf app.jar | grep -i log4j2

# Point at it explicitly while you debug, which also proves the path
java -Dlog4j2.configurationFile=./log4j2.xml -jar app.jar

# Make Log4j explain its own lookup
java -Dlog4j2.debug=true -jar app.jar

<!-- src/main/resources/log4j2.xml -->
<Configuration status="WARN">
  <Appenders>
    <Console name="console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{ISO8601} %-5level %logger{36} - %msg%n"/>
    </Console>
  </Appenders>
  <Loggers>
    <Root level="info"><AppenderRef ref="console"/></Root>
  </Loggers>
</Configuration>

# A fat jar with several log4j2.xml files uses whichever comes first,
# so exclude the ones shipped by dependencies rather than hoping

How to diagnose Logging errors

Logging failures are dangerous because they are silent: the application keeps running while its telemetry disappears. The recurring causes are buffer overflow under backpressure (the destination cannot keep up), permissions on log files or directories, and ingestion rate limits at the cloud provider. Monitoring the logging pipeline itself is the only reliable way to notice.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

Check the collector's own logs first: Fluentd, Logstash and the CloudWatch agent all log their own failures, usually to a separate destination.
Look for backpressure metrics: buffer queue length, retry counts, and dropped-record counters. A full buffer means the destination, not the collector, is the bottleneck.
Verify write permissions and disk space on the buffer path. A full disk silently stops most collectors.
For cloud ingestion, check the API rate limit for the log group or stream and batch more aggressively rather than retrying harder.
Add a heartbeat log line and alert on its absence. This is the only way to detect a pipeline that has stopped without erroring.

Tools worth reaching for

collector self-logs
buffer/queue metrics
df -h
aws logs describe-log-streams
logger / fluent-cat for test events

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

logging.apache.org logging.apache.org

Related Logging errors

See all 12 Logging errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.