anchor.diff:  
   		@Override
   		public Health health() {
  -			// perform some specific health check
  -			return ...
  +			int errorCode = check(); // perform some specific health check
  +			if (errorCode != 0) {
  +				return Health.down().withDetail("Error Code", errorCode);
  +			}
  +			return Health.up();
   		}
   
   	}
   ----
   
  -Spring Boot provides a
  -{sc-spring-boot-actuator}/health/DataSourceHealthIndicator.{sc-ext}[`DataSourceHealthIndicator`]
  -implementation that attempts a simple database test (reusing the validation query set on the data
  -source, if any) as well as implementations for Redis, MongoDB and RabbitMQ. Spring Boot adds the
  -`HealthIndicator` instances automatically if beans of type `DataSource`, `MongoTemplate`,
  -`RedisConnectionFactory`, and `RabbitTemplate` respectively are present in the
  -`ApplicationContext`. A health indicator that checks free disk space is also provided.
  -
  -Besides implementing custom a `HealthIndicator` type and using out-of-box {sc-spring-boot-actuator}/health/Status.{sc-ext}[`Status`]
  -types, it is also possible to introduce custom `Status` types for different or more complex system
  -states. In that case a custom implementation of the {sc-spring-boot-actuator}/health/HealthAggregator.{sc-ext}[`HealthAggregator`]
  -interface needs to be provided or the default implementation has to be configured using the
  -`management.health.status.order` configuration property.
  -
  -Assuming a new `Status` with code `FATAL` is being used in one of your `HealthIndicator`
  -implementations. To configure the severity or order add the following to your application properties:
  -`management.health.status.order: DOWN, OUT_OF_SERVICE, UNKNOWN, UP`.
  +In addition to Spring Boot's default {sc-spring-boot-actuator}/health/Status.{sc-ext}[`Status`]
  +types, it is also possible to introduce custom `Status` types to represent more
  +complex system states. In such cases a custom implementation of the
  +{sc-spring-boot-actuator}/health/HealthAggregator.{sc-ext}[`HealthAggregator`]
  +interface also needs to be provided, or the default implementation has to be configured
  +using the `management.health.status.order` configuration property.
  +
  +For example, assuming a new `Status` with code `FATAL` is being used in one of your
  +`HealthIndicator` implementations. To configure the severity order add the following
  +to your application properties:
  +
  +[source,properties,indent=0]
  +----
  +	management.health.status.order: DOWN, OUT_OF_SERVICE, UNKNOWN, UP
  +----
  +
  +You might also want to register custom status mappings with the `HealthMvcEndpoint`
  +if you access the health endpoint over HTTP. For example you could map `FATAL` to
  +`HttpStatus.SERVICE_UNAVAILABLE`.
   
   
   
  
positive.code: 
  
  [[production-ready-health-access-restrictions]]
  === Health endpoint anonymous access restrictions
  The information exposed by the health endpoint varies depending on whether or not it's
  accessed anonymously. By default, when accessed anonymously, any details about the
  server's health are hidden and the endpoint will simply indicate whether or not the server
  
negative.code: |true
  
  |`health`
  |Shows full application health information when accessed securely or a simple '`status`'
  message when accessed over an insecure HTTP connection.
  |true
  
  |`info`
  |Displays arbitrary application info.
  