Introduction

A frequent Spring Boot logging question is: "Where are my logs written by default?" The short answer is that Spring Boot logs to the console by default and does not create a log file unless you configure one. This surprises teams coming from app servers where file logging is preconfigured.

Understanding default behavior and explicit file configuration is important for production deployment, especially in containers and Kubernetes where log routing strategy affects observability and retention.

Core Sections

1. Default logging behavior in Spring Boot

Out of the box, Spring Boot configures a logging system (typically Logback) and writes application logs to standard output.

1import org.slf4j.Logger;
2import org.slf4j.LoggerFactory;
3import org.springframework.web.bind.annotation.GetMapping;
4import org.springframework.web.bind.annotation.RestController;
5
6@RestController
7class HealthController {
8    private static final Logger log = LoggerFactory.getLogger(HealthController.class);
9
10    @GetMapping("/health")
11    String health() {
12        log.info("Health endpoint called");
13        return "ok";
14    }
15}

Run the app and logs appear in terminal. No file is created unless you set a file property or custom logback appender.

2. Configure log file name and location explicitly

In modern Spring Boot, use:

• logging.file.name to set full file path/name.
• logging.file.path to set directory for default file naming.

1# application.properties
2logging.file.name=/var/log/myapp/application.log
3logging.level.root=INFO
4logging.level.com.example=DEBUG

Or:

logging.file.path=/var/log/myapp

If the directory is not writable, file logging fails or silently falls back depending on environment and logging backend configuration. Always verify permissions at deploy time.

For custom rolling policies, define logback-spring.xml.

1<configuration>
2  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
3    <file>/var/log/myapp/app.log</file>
4    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
5      <fileNamePattern>/var/log/myapp/app.%d{yyyy-MM-dd}.log</fileNamePattern>
6      <maxHistory>14</maxHistory>
7    </rollingPolicy>
8    <encoder>
9      <pattern>%d %-5level [%thread] %logger - %msg%n</pattern>
10    </encoder>
11  </appender>
12
13  <root level="INFO">
14    <appender-ref ref="FILE"/>
15  </root>
16</configuration>

3. Production strategy: console vs file in containers

In Kubernetes and most container platforms, best practice is usually console logging plus centralized collection (Fluent Bit, CloudWatch, ELK, etc.). Writing local files inside ephemeral containers often complicates retention and rotation.

If you do require files (compliance, sidecar tailing, legacy integration), mount persistent volumes and configure rotation. Test startup behavior when disk is full or path is missing.

Use environment variables to control location per environment:

export LOGGING_FILE_NAME=/var/log/myapp/app.log

Spring Boot maps uppercase underscore env vars to property names.

Common Pitfalls

• Assuming Spring Boot writes a file by default when it only logs to console initially.
• Using deprecated/old property names from outdated examples without checking current Boot version.
• Configuring file path to non-writable directories and missing startup/runtime log errors.
• Writing logs to container filesystem without retention strategy in orchestrated environments.
• Mixing custom logback.xml and application properties in conflicting ways.

Summary

Spring Boot’s default log location is standard output, not a file. Set logging.file.name or logging.file.path when file logging is required, and use logback-spring.xml for advanced rotation policies. In containerized systems, prefer console logs with centralized aggregation unless there is a strong reason to persist local log files.

For enterprise environments, standardize logging configuration per environment profile. Development may prefer colorful console output, while production may require JSON-formatted logs for ingestion into observability platforms. Keep these variants in profile-specific configuration or conditional logback appenders, and verify startup behavior in each environment. Consistency here reduces "works locally" logging surprises.

Also include correlation identifiers (request IDs, trace IDs) in your log pattern early. Log location is only part of the observability story; log context quality determines whether incidents are diagnosable. Even with perfect file placement, logs without trace context are harder to use during high-pressure debugging.

Treat logging setup as deploy-time infrastructure, not an afterthought, and review it alongside tracing and metrics configuration.

A quick startup smoke test that confirms expected destination and rotation behavior can prevent difficult production logging incidents.

This small discipline pays off quickly in incident response.