/actuator/health — это не просто проверка, что приложение живо

И показать разницу:
/actuator/health
│
├── liveness → процесс приложения вообще жив?
│
└── readiness → приложение готово принимать трафик?

И интересный нюанс: UP не означает, что приложение действительно готово нормально работать. В health могут участвовать DB, Kafka, Redis и другие HealthIndicator.
Например:
management:
endpoint:
health:
probes:
enabled: true

Тогда появляются:
/actuator/health/liveness
/actuator/health/readiness

И Kubernetes может использовать их отдельно:
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080

readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080

Почему нельзя бездумно запихивать БД/Kafka во liveness?
Если БД легла:

DB down
↓
health = DOWN
↓
liveness = DOWN
↓
Kubernetes рестартит Pod
↓
Pod снова стартует
↓
DB всё ещё down
↓
рестарт...
То есть мы можем превратить временную проблему внешней зависимости в бесконечный CrashLoop. А вот для readiness это уже имеет смысл:

DB down
↓
readiness = DOWN
↓
Pod остаётся запущенным
↓
Service перестаёт слать ему новый трафик