Introduction

If /actuator/health/liveness and /actuator/health/readiness return 404, the application is usually alive but the probe endpoints are not exposed at the path Kubernetes expects. The fix is almost always in configuration: missing Actuator dependency, incorrect management path or port, or health probes not being enabled for the Spring Boot version you are running.

Verify the base health endpoint first

Before debugging probe-specific URLs, confirm that the ordinary health endpoint exists.

curl -i http://localhost:8080/actuator/health

If that already returns 404, the problem is broader than liveness and readiness. In that case, start by checking whether Actuator is on the classpath and whether health is exposed over HTTP.

Make sure Actuator is installed

Without the Actuator starter, none of the /actuator endpoints exist.

Maven:

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

Gradle:

implementation("org.springframework.boot:spring-boot-starter-actuator")

This sounds obvious, but many 404 reports come from deployments where the dependency was removed or never included in the first place.

Expose health endpoints over the web

Spring Boot does not expose every management endpoint automatically. If health is not included in web exposure, the probe paths will not be reachable either.

1management:
2  endpoints:
3    web:
4      exposure:
5        include: health,info

In properties form:

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

This enables HTTP access to the health endpoint family.

Enable liveness and readiness probes

Probe-specific health groups are version-sensitive in Spring Boot. In many setups, you need to enable probe support explicitly.

1management:
2  endpoint:
3    health:
4      probes:
5        enabled: true

After that, the expected URLs are usually:

• '/actuator/health/liveness'
• '/actuator/health/readiness'

If your Spring Boot version behaves differently, the key debugging step is still the same: inspect which health groups actually exist rather than assuming the probe paths are active by default.

Check custom management path and port

A very common reason for 404 is that the management endpoints are not under /actuator on the main app port.

For example:

1management:
2  server:
3    port: 8081
4  endpoints:
5    web:
6      base-path: /manage

With that configuration, the readiness endpoint becomes:

http://localhost:8081/manage/health/readiness

If Kubernetes is still probing http://localhost:8080/actuator/health/readiness, it will get 404 even though the application is configured correctly.

Example working configuration

A minimal setup that often works in container environments looks like this:

1management:
2  endpoints:
3    web:
4      exposure:
5        include: health,info
6  endpoint:
7    health:
8      probes:
9        enabled: true

Then verify it locally:

curl -i http://localhost:8080/actuator/health
curl -i http://localhost:8080/actuator/health/liveness
curl -i http://localhost:8080/actuator/health/readiness

Only after those succeed should the Kubernetes probes be pointed at the same paths.

Align Kubernetes probes with the actual endpoint

Once the application exposes the health groups, configure the deployment to match the real path and port.

1livenessProbe:
2  httpGet:
3    path: /actuator/health/liveness
4    port: 8080
5
6readinessProbe:
7  httpGet:
8    path: /actuator/health/readiness
9    port: 8080

If the management port or base path changes, update the probe spec as well. Many probe failures are just stale deployment YAML.

Common Pitfalls

The most common mistake is assuming the problem is in Kubernetes before verifying the endpoints locally. If curl returns 404 on the pod itself, the cluster is not the root cause.

Another issue is enabling Actuator but forgetting to expose health endpoints over HTTP. The starter dependency alone is not enough.

Teams also get bitten by custom management paths and ports. When the endpoint moves to /manage or to port 8081, old probe definitions keep hitting the wrong location.

Finally, remember that probe behavior has changed across Spring Boot versions. If you upgraded the application and the old paths stopped working, review the management and health configuration rather than assuming a runtime bug.

Summary

• Start with /actuator/health before checking liveness and readiness paths.
• Confirm the Actuator starter is present and health is exposed over HTTP.
• Enable probe support when your Spring Boot version requires it.
• Verify the real management base path and port before configuring Kubernetes.
• Keep deployment probe URLs aligned with the actual Actuator configuration.