Do /actuator/health/liveness and /actuator/health/readiness exist automatically on every Spring Boot app?

No, these are separate health groups that need to be explicitly enabled in the Spring Boot application (via the management.endpoint.health.probes.enabled configuration property, among Spring Boot's standard Actuator health-group setup), an application without this enabled only has the generic /actuator/health endpoint, and pointing both probes at endpoints that don't exist causes probe failures, not a graceful fallback to the generic health endpoint.

What's the practical difference the platform draws between liveness and readiness probe failures?

A liveness probe failure generally results in the instance being considered unhealthy and eligible for restart, since it indicates the application itself is in a broken state. A readiness probe failure means the instance is temporarily not ready to receive traffic (still starting up, or briefly overloaded) without necessarily being broken, so it's removed from traffic rotation without being restarted. Configuring both correctly, pointing at genuinely distinct signals, lets the platform make the right decision for each failure type instead of treating every health issue the same way.

Does using the managed applicationConfigurationService addon eliminate the need to run Spring Cloud Config Server separately?

Yes, that's exactly its purpose, it's Azure's managed equivalent providing the same externalized-configuration capability Spring Cloud Config Server provides, without needing to deploy, scale, and operate that component yourself. Your Spring Boot app still uses standard Spring Cloud Config client behavior to consume it, the difference is entirely on the server side being platform-managed.

Azure Spring Apps Config Builder

ComputeAzure

Build Spring Apps deployment configs with runtime settings, autoscaling, health probes, config server, and service registry.

Azure Spring Apps Configuration

Build Spring Apps deployment configs with runtime settings, autoscaling, health probes, config server, service registry, and ingress.

Required Fields

serviceNameresourceGroupappNamedeployment.source.runtimeVersiondeployment.deploymentSettings.resourceRequestsdeployment.deploymentSettings.scale

{
  "serviceName": "asa-contoso-prod",
  "resourceGroup": "rg-spring-apps",
  "location": "eastus2",
  "sku": "Enterprise",
  "appName": "order-service",
  "deployment": {
    "name": "default",
    "source": {
      "type": "Jar",
      "relativePath": "<default>",
      "runtimeVersion": "Java_17"
    },
    "deploymentSettings": {
      "resourceRequests": {
        "cpu": "2",
        "memory": "4Gi"
      },
      "scale": {
        "minReplicas": 2,
        "maxReplicas": 10,
        "rules": [
          {
            "name": "cpu-scaling",
            "type": "cpu",
            "metadata": {
              "averageUtilization": "70"
            }
          }
        ]
      },
      "environmentVariables": {
        "SPRING_PROFILES_ACTIVE": "prod",
        "SPRING_CLOUD_CONFIG_URI": "https://config-server.contoso.internal",
        "SERVER_PORT": "8080",
        "MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE": "health,info,metrics,prometheus"
      },
      "addonConfigs": {
        "applicationConfigurationService": {
          "configFilePatterns": "order-service/prod"
        },
        "serviceRegistry": {
          "enabled": true
        }
      },
      "livenessProbe": {
        "probeAction": {
          "type": "HTTPGetAction",
          "path": "/actuator/health/liveness",
          "port": 8080
        },
        "initialDelaySeconds": 30,
        "periodSeconds": 10,
        "failureThreshold": 3
      },
      "readinessProbe": {
        "probeAction": {
          "type": "HTTPGetAction",
          "path": "/actuator/health/readiness",
          "port": 8080
        },
        "initialDelaySeconds": 15,
        "periodSeconds": 5,
        "failureThreshold": 5
      }
    }
  },
  "ingress": {
    "isPublic": true,
    "targetPort": 8080,
    "exposedPort": 443,
    "transport": "http1",
    "sessionAffinity": "None",
    "clientAuth": {
      "certificates": []
    }
  },
  "customDomain": {
    "name": "orders.contoso.com",
    "certName": "wildcard-contoso-com"
  },
  "persistentStorage": {
    "mountPath": "/data",
    "sizeInGB": 50,
    "storageAccountName": "stcontosospringdata"
  }
}

Generated Output

Output will appear here...

What This Tool Does

Build an Azure Spring Apps deployment with resourceRequests sizing, CPU-based autoscaling rules, liveness/readiness probes hitting Spring Boot Actuator endpoints, and addonConfigs wiring in the platform's built-in Application Configuration Service and Service Registry (Spring Cloud Config Server and Eureka-equivalent managed for you). livenessProbe and readinessProbe target genuinely different Actuator health groups (/actuator/health/liveness vs /actuator/health/readiness), which only exist as separate endpoints if the Spring Boot application has actually enabled Spring Boot's liveness/readiness health group support, an app not configured for this returns the same combined health status for both probes, defeating the point of having distinct liveness (restart-worthy) versus readiness (traffic-worthy) signals.

Technical Details

The builder validates that serviceName, resourceGroup, appName, deployment.source.runtimeVersion, deployment.deploymentSettings.resourceRequests, and deployment.deploymentSettings.scale all resolve before accepting the JSON as a valid Spring Apps deployment definition, the fields Azure needs to know the app's runtime, resource sizing, and scaling bounds; it can't verify the referenced Actuator health endpoints actually exist on the deployed application or that the application is built with Spring Cloud client support for the enabled addons, those are only surfaced once the deployment actually runs.

Common Use Cases

1Pointing livenessProbe and readinessProbe at the distinct /actuator/health/liveness and /actuator/health/readiness endpoints specifically, rather than both hitting the generic /actuator/health, so Kubernetes-style liveness (should this instance be restarted) and readiness (should this instance receive traffic) concerns are actually evaluated independently.
2Enabling addonConfigs.applicationConfigurationService with a specific configFilePatterns scope, so the app pulls externalized configuration from the managed Config Server without needing to stand up and operate a separate Spring Cloud Config Server instance.
3Enabling addonConfigs.serviceRegistry so this app can discover and be discovered by other Spring Apps deployments in the same service, using the platform's managed service registry instead of self-hosting Eureka.
4Setting scale.rules with a cpu-scaling rule targeting 70% average utilization, so replica count grows under real load between minReplicas and maxReplicas rather than running a fixed instance count sized for peak load at all times.

Common Questions

Do /actuator/health/liveness and /actuator/health/readiness exist automatically on every Spring Boot app?: No, these are separate health groups that need to be explicitly enabled in the Spring Boot application (via the management.endpoint.health.probes.enabled configuration property, among Spring Boot's standard Actuator health-group setup), an application without this enabled only has the generic /actuator/health endpoint, and pointing both probes at endpoints that don't exist causes probe failures, not a graceful fallback to the generic health endpoint.
What's the practical difference the platform draws between liveness and readiness probe failures?: A liveness probe failure generally results in the instance being considered unhealthy and eligible for restart, since it indicates the application itself is in a broken state. A readiness probe failure means the instance is temporarily not ready to receive traffic (still starting up, or briefly overloaded) without necessarily being broken, so it's removed from traffic rotation without being restarted. Configuring both correctly, pointing at genuinely distinct signals, lets the platform make the right decision for each failure type instead of treating every health issue the same way.
Does using the managed applicationConfigurationService addon eliminate the need to run Spring Cloud Config Server separately?: Yes, that's exactly its purpose, it's Azure's managed equivalent providing the same externalized-configuration capability Spring Cloud Config Server provides, without needing to deploy, scale, and operate that component yourself. Your Spring Boot app still uses standard Spring Cloud Config client behavior to consume it, the difference is entirely on the server side being platform-managed.

Expert Tips

TIP

Verify the Spring Boot application actually has liveness/readiness health groups enabled before configuring separate probe paths for each, otherwise both probes fail against non-existent endpoints, which is worse than pointing both at the generic /actuator/health that does exist.

TIP

The managed Application Configuration Service and Service Registry addons remove real operational burden (running your own Config Server and Eureka), but do require the application to be built with standard Spring Cloud client libraries expecting this integration pattern, verify compatibility for an app not originally built with Spring Cloud in mind.

TIP

Size cpu-scaling's averageUtilization threshold based on the application's actual CPU-to-latency relationship under load, a threshold set too high means the app is already struggling by the time autoscaling reacts, one set too low causes unnecessary scale-out churn from routine load variation.

Related Learning Guides

Azure VM Series Guide22 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.