Actuators: Types, Operation, Selection, and Control

Spring Boot Actuator Logfile Endpoint

Learn how to configure, expose, secure, and troubleshoot the Spring Boot Actuator logfile endpoint for retrieving application log output.

The Spring Boot Actuator logfile endpoint serves the contents of an application's active log file over a management interface. It is useful when an operator needs application output but does not have direct access to the server filesystem.

What the logfile endpoint does

Spring Boot Actuator is Spring Boot's production-ready monitoring and management feature set. An Actuator management endpoint provides a management function through a transport such as HTTP or JMX.

The endpoint ID for log-file retrieval is logfile. With the usual management base path, its web route is:

GET /actuator/logfile

The endpoint reads and returns the configured application log file. The response is normally plain-text log content, not a structured JSON document.

This endpoint is different from the Actuator loggers endpoint. The logfile endpoint retrieves recorded output; the loggers endpoint is used to inspect or change logger levels. Retrieval does not change logging configuration.

Useful operational cases

  • Inspecting startup failures after an application has started or failed partially.
  • Reviewing recent exceptions, warnings, and request failures.
  • Supporting a restricted environment where an operator cannot log in to the host.
  • Collecting a small portion of a large log through an HTTP Range request.

Availability, enablement, and exposure

Three conditions commonly determine whether the route works:

  1. The application includes Actuator support.
  2. The logfile endpoint is enabled.
  3. The endpoint is exposed through the transport being used, such as HTTP.

Endpoint enablement means that the endpoint is available to run. Endpoint exposure means that an available endpoint is made accessible through a particular technology, such as HTTP. An enabled endpoint can still return 404 if it is not exposed over HTTP.

The usual management base path is /actuator, but it can be changed. A separate management port can also change the host and port used by the route. Verify the defaults for the Spring Boot release in use because exposed endpoint defaults and security behavior vary between releases.

Prerequisites

  • A Spring Boot application with the Actuator dependency.
  • Application logging configured to write to a file, not only to the console.
  • An active file that Spring Boot can discover and read.
  • A writable log directory and suitable ownership and permissions when the application creates the file.

Add Actuator

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
implementation("org.springframework.boot:spring-boot-starter-actuator")

Console-only logging does not create a file for this endpoint to serve. In that configuration, the route may be exposed but still report that no log file is available.

Configure the application log file

Set a specific file with logging.file.name

logging.file.name specifies a concrete file name or path. An absolute path is usually easier to operate because it avoids ambiguity about the process working directory.

logging.file.name=/var/log/myapp/application.log
management.endpoints.web.exposure.include=health,info,logfile

Set a directory with logging.file.path

logging.file.path specifies the directory used for file logging. Spring Boot then chooses the default log-file name according to the applicable Spring Boot version and logging setup. Do not assume that a directory setting produces the same filename in every release; verify the effective configuration.

logging.file.path=/var/log/myapp
management.endpoints.web.exposure.include=health,info,logfile

Use a custom logging framework configuration

A custom Logback or Log4j2 configuration can write to a file appender. The logfile endpoint must be able to discover the active file location. If the custom configuration writes to a destination that Spring Boot does not know about, the endpoint may be unavailable or may return a different file than expected.

Check the effective Logback or Log4j2 configuration, use absolute paths where practical, and confirm that the file returned by the endpoint is the file written by the running instance.

Filesystem and rotation concerns

  • The application process needs write permission to create or append to the file.
  • The process serving Actuator needs read permission for the active file.
  • The directory must exist and be writable, including inside a container.
  • External rotation tools and logging-framework rolling appenders can rename, replace, compress, or delete files while a request is in progress.
  • After rotation, confirm which file is considered active and whether the endpoint can still discover it.
  • In a container, a local file may disappear when the workload is replaced unless it is stored on a mounted volume.

Expose only the endpoint you need

Current Spring Boot configuration commonly uses management.endpoints.web.exposure.include to select HTTP endpoints. Expose only the endpoints required by operators rather than broadly exposing sensitive management functions.

management.endpoints.web.exposure.include=health,info,logfile

The equivalent YAML is:

logging:
  file:
    name: /var/log/myapp/application.log
management:
  endpoints:
    web:
      exposure:
        include: health,info,logfile

Exclusion rules can remove an endpoint from web exposure when a broader include setting exists:

management.endpoints.web.exposure.exclude=env,configprops,heapdump

Use the narrowest, clearest configuration for the release you run. Do not treat legacy management property conventions as interchangeable with current property names. Also distinguish web exposure from JMX exposure: making an endpoint available through one transport does not automatically make it available through another.

Configuration reference

Set a specific log file — logging.file.name — logging.file.name=/var/log/myapp/application.log — Points file logging at a concrete path.

Set a log directory — logging.file.path — logging.file.path=/var/log/myapp — Spring Boot selects the default file behavior for the applicable release.

Expose logfile over web — management.endpoints.web.exposure.include — health,info,logfile — Include only the HTTP endpoints that operators need.

Set a management base path — management.endpoints.web.base-path — /manage — Changes the route to /manage/logfile.

Use a separate management port — management.server.port — 8081 — Places management endpoints on a dedicated port.

Disable the endpoint — management.endpoint.logfile.enabled — false — Prevents the endpoint from being available.

Request and response behavior

Retrieve the complete response with an HTTP GET:

curl -u operator:password http://localhost:8080/actuator/logfile

The response contains plain-text log lines. Depending on the Spring Boot version, HTTP server, and resource state, useful response details include a text content type, a full-file success response, and a partial response for a valid byte range.

Retrieve part of a large file

An HTTP Range request asks for selected bytes of a resource. This can avoid transferring an entire large log. The following requests the final 8192 bytes:

curl -u operator:password -H "Range: bytes=-8192" http://localhost:8080/actuator/logfile

A successful range response commonly uses status 206 Partial Content and includes a Content-Range header. Range support depends on the Spring Boot version and the underlying web resource handling, so inspect the actual status and headers rather than assuming every deployment behaves identically.

If the file is absent, deleted during rotation, inaccessible, or not discoverable, the endpoint can report that no log file is available or return another error response. An empty response can also indicate that the active file exists but contains no output yet.

Secure the endpoint

Application logs can contain usernames, request parameters, hostnames, internal paths, stack traces, database details, session identifiers, tokens, or other sensitive data. Treat logfile access as privileged access.

  • Require authentication and authorization in production.
  • Give access only to an operations role that needs it.
  • Prefer a dedicated management port or management-only network interface.
  • Use TLS for remote management traffic.
  • Restrict access with firewalls, ingress rules, reverse proxies, or private network controls.
  • Audit successful and failed access where operationally appropriate.
  • Redact secrets in application logs; endpoint protection is not a substitute for safe logging.

Spring Security example

This example requires an authenticated user with the OPS role for the logfile route:

@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
  return http
      .authorizeHttpRequests(auth -> auth
          .requestMatchers("/actuator/logfile").hasRole("OPS")
          .anyRequest().authenticated())
      .httpBasic(withDefaults())
      .build();
}

If the management base path is changed, match the actual path. If management runs on another port, apply network and proxy controls to that management interface as well.

Separate management interface

management.server.port=8081
management.endpoints.web.base-path=/manage

The route in this example is http://localhost:8081/manage/logfile. A separate port is useful only when it is actually isolated; exposing that port publicly without authentication or network restrictions does not improve security.

Deployment considerations

Traditional servers

On a traditional host, confirm the service user's ownership and read permissions, the location used by the rolling policy, and the behavior of external tools such as logrotate. Coordinate external rotation with Logback or Log4j2 rolling appenders to avoid losing the active file or causing the application and rotation tool to disagree about file ownership.

Containers and orchestration

Container filesystems may be ephemeral, read-only, or different from the host filesystem. If file retrieval is required, write to a mounted directory that exists in the running workload and is readable by the application process. A volume can preserve or share files, but it also introduces permissions, capacity, and rotation responsibilities.

For production container platforms, applications commonly write to standard output and use centralized logging: sending logs to a dedicated aggregation system. This is usually better for searching logs across replicas and retaining them after a container is replaced. The logfile endpoint can remain useful for local diagnostics, but it should not be the only copy of production logs.

Operational suitability

Local development — Convenient for inspecting a file-backed log — Basic authentication or local-only access — Keep console output and a local file; use the endpoint for quick checks.

Internal test environment — Useful for test failures and startup diagnostics — Restrict to test operators and private networks — Pair with test log collection and retention.

Traditional server deployment — Practical when operators have limited shell access — TLS, authentication, least-privilege roles, and audited access — Coordinate with rolling files and host-level log collection.

Container platform production — Useful only when a mounted active file is intentionally maintained — Management-only networking and strong authorization — Prefer centralized logging for aggregation, search, retention, and replica-wide visibility.

Troubleshooting

404 Not Found

Check for the Actuator dependency, the management port, the management base path, endpoint enablement, and HTTP exposure. A typical resolution is:

  1. Confirm Actuator is present in the application dependencies and startup output.
  2. Confirm the route uses the configured management port and base path.
  3. Add logfile to management.endpoints.web.exposure.include.
  4. Check that management.endpoint.logfile.enabled has not been set to false.

401 Unauthorized or 403 Forbidden

A 401 usually means credentials are missing or invalid. A 403 usually means authentication succeeded but the user lacks the required authority. Review Spring Security matchers, role naming, authentication providers, reverse-proxy rules, firewall rules, and ingress policies.

No log file, not found, or unavailable output

Check whether logging is console-only, whether the configured path is correct, whether the file was removed or replaced during rotation, and whether the process can read it. Verify the file from inside the running environment, not only from the host or development machine.

Empty or unexpected output

An empty file may simply have no entries yet. Unexpected content often means a custom Logback or Log4j2 configuration writes elsewhere, multiple instances use different local files, or a relative path resolves against an unexpected working directory. Inspect the effective logging configuration, prefer an absolute path, and confirm that the request reaches the intended instance.

Failures after rotation or deployment

Review rolling policies, external rotation behavior, active-file naming, and permissions after a file is renamed or replaced. In containers, inspect whether the directory exists, is writable and readable, is mounted at the configured path, and persists for the expected lifetime. If logs are emitted only to standard output, use the platform's centralized logging workflow instead.

Common responses and causes

404 Not Found — Missing Actuator support, changed base path or port, disabled endpoint, or missing HTTP exposure — Check dependencies, management settings, enablement, and exposure — Correct the route or expose and enable logfile.

401 Unauthorized — Missing or invalid authentication — Inspect credentials and authentication configuration — Authenticate using the configured mechanism.

403 Forbidden — Authenticated user lacks the required role, or a network policy denies access — Review authorization rules and proxy or firewall logs — Grant the least-privilege operator role or adjust the policy.

No log file available — Console-only logging, wrong path, deleted file, or unreadable file — Inspect the active environment and file permissions — Configure a discoverable file and correct ownership or permissions.

Empty or unexpected output — No entries yet or a custom appender writes to another file — Inspect effective logging configuration and instance selection — Use the correct absolute path and target the intended instance.

Partial-content response — A valid HTTP Range request was honored — Inspect status and Content-Range — Process only the requested segment and account for rotation while reading.

Version-aware checklist

  • Confirm the Spring Boot release before relying on endpoint exposure defaults.
  • Use the current property names for endpoint exposure, enablement, base path, and management server configuration.
  • Verify whether the active logging setup is Spring Boot's default configuration or a custom Logback or Log4j2 configuration.
  • Test the actual management port, path, response content type, and range behavior in the deployed release.
  • Review Spring Security configuration because authorization APIs and defaults can change between releases.

Practical workflow

  1. Add spring-boot-starter-actuator.
  2. Configure logging.file.name, logging.file.path, or a discoverable custom file appender.
  3. Ensure the running process can create and read the file.
  4. Enable the endpoint if it has been disabled.
  5. Expose only logfile and other required endpoints over HTTP.
  6. Secure the route with authentication, an operator role, TLS, and network restrictions.
  7. Call the route with GET and inspect the plain-text response.
  8. For large files, test a Range request and check for 206 Partial Content.
  9. Use centralized logging for retention, searching, and multi-instance production observability.

For broader Actuator context, see Spring Boot Actuator. Related endpoints include Logfile, Env, Configprops, Mappings, Httptrace, and Heapdump.