Spring Boot
Actuator
Metrics Endpoint
Troubleshooting
Version 2

Spring Boot 2 - Actuator Metrics Endpoint not working

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

If /actuator/metrics is not working in Spring Boot 2, the problem is usually endpoint exposure, security rules, or management port configuration. Boot 2 uses Actuator with Micrometer, so metrics availability depends on both dependency setup and runtime configuration. A systematic checklist resolves most failures quickly.

Confirm Required Dependencies

At minimum, include Actuator starter.

xml
1<dependency>
2  <groupId>org.springframework.boot</groupId>
3  <artifactId>spring-boot-starter-actuator</artifactId>
4</dependency>

For backend registries, include corresponding Micrometer module, for example Prometheus.

xml
1<dependency>
2  <groupId>io.micrometer</groupId>
3  <artifactId>micrometer-registry-prometheus</artifactId>
4</dependency>

Missing dependencies can lead to empty or partial metric output.

Expose Metrics Endpoint Explicitly

In Boot 2, actuator endpoints are not all exposed over HTTP by default. Configure exposure intentionally.

properties
management.endpoints.web.exposure.include=health,info,metrics
management.endpoint.metrics.enabled=true

Then test endpoints:

  • '/actuator'
  • '/actuator/metrics'
  • '/actuator/metrics/jvm.memory.used'

If /actuator does not show metrics, exposure config is the first place to check.

Check Management Port and Base Path

Actuator may be served on a different port or base path.

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

With this setup, metrics live at http://host:8081/actuator/metrics, not the main app port.

Verify Spring Security Rules

Security configuration can block actuator endpoints. Define explicit rules for operational access.

java
1import org.springframework.context.annotation.Bean;
2import org.springframework.security.config.annotation.web.builders.HttpSecurity;
3import org.springframework.security.web.SecurityFilterChain;
4
5@Bean
6SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
7    http
8        .authorizeHttpRequests(auth -> auth
9            .requestMatchers("/actuator/health", "/actuator/info").permitAll()
10            .requestMatchers("/actuator/**").hasRole("ACTUATOR")
11            .anyRequest().authenticated()
12        )
13        .httpBasic();
14
15    return http.build();
16}

Adapt this to your environment and least-privilege policy.

Understand Metric Name Discovery

/actuator/metrics returns available names. To inspect a specific metric, query by name.

bash
curl http://localhost:8080/actuator/metrics
curl http://localhost:8080/actuator/metrics/http.server.requests

Some metrics appear only after corresponding application activity.

Diagnostic Sequence

Use this order to reduce troubleshooting time:

  1. verify actuator dependency in runtime artifact
  2. call /actuator and inspect listed endpoints
  3. check exposure and base-path properties
  4. verify management port settings
  5. inspect security logs for denied requests
  6. query specific metric names after traffic

This sequence catches most real-world configuration errors.

Environment Profile Drift

Metrics working locally but not in staging often means profile-specific config drift. Check active profiles and effective properties in each environment. Keep actuator-related settings versioned and reviewed like application code.

A useful startup log line is printing active management port and base path so endpoint URLs are unambiguous in logs.

Production Hardening

Expose only required actuator endpoints in production. Place them behind internal networking controls, authentication, and monitoring policy. Avoid broad endpoint exposure such as wildcard includes unless there is a clear operational reason. Metrics endpoints are operational interfaces and should be treated with the same security care as admin APIs.

Quick Verification Script

After configuration changes, run a repeatable verification sequence so team members validate endpoints the same way.

bash
1BASE_URL="http://localhost:8080"
2
3curl -sf "${BASE_URL}/actuator" | jq '.'
4curl -sf "${BASE_URL}/actuator/metrics" | jq '.names | length'
5curl -sf "${BASE_URL}/actuator/metrics/jvm.memory.used" | jq '.measurements'

This script confirms endpoint visibility, available metric names, and one concrete metric payload.

Common Pitfalls

A common pitfall is following Boot 1 examples in Boot 2 projects, resulting in wrong endpoint assumptions. Another is forgetting that exposure defaults are restrictive. Teams often query the main app port while actuator runs on management port. Security blocks are also frequently misdiagnosed as missing metrics. Finally, registry dependencies are omitted and teams expect external backend integration to work automatically.

Summary

  • Ensure Actuator and required Micrometer dependencies are present.
  • Expose /metrics explicitly in Boot 2 configuration.
  • Verify management port and base path before testing URLs.
  • Confirm security rules allow intended actuator access.
  • Query specific metric names after real traffic is generated.
  • Treat actuator configuration and hardening as part of production architecture.

Related reading
Course
Intermediate
27 lessons
14 hours
OOD Fundamentals

Master object-oriented design from first principles, SOLID, design patterns, and classic interview problems with hands-on coding.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.