Health endpoint customization in Spring Boot - Step-by-Step Execution

Concept Flow - Health endpoint customization

Start Spring Boot App

↓

Health Endpoint Enabled

↓

Customize Health Indicator

↓

Add Custom Health Logic

↓

Health Endpoint Returns Custom Status

↓

Client Calls /actuator/health

↓

Receive Custom Health Response

The app starts, enables the health endpoint, applies custom health checks, and returns the customized health status when called.

Execution Sample

Spring Boot

import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;

@Component
public class CustomHealthIndicator implements HealthIndicator {
  @Override
  public Health health() {
    return Health.up().withDetail("custom", "All systems go").build();
  }
}

Defines a custom health indicator that reports the app is up with a custom detail message.

Execution Table

Step	Action	Evaluation	Result
1	Spring Boot starts	Health endpoint enabled by default	Health endpoint available at /actuator/health
2	CustomHealthIndicator bean created	Overrides default health check	Custom health logic ready
3	Health endpoint called by client	Calls CustomHealthIndicator.health()	Returns status UP with detail {custom: 'All systems go'}
4	Client receives response	Parses JSON with status and details	Sees custom health status and message
5	No errors	Health endpoint works as customized	Process ends successfully

💡 Health endpoint returns custom status and details, completing the health check cycle

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
healthStatus	null	null	UP	UP
healthDetails	{}	{}	{"custom":"All systems go"}	{"custom":"All systems go"}

Key Moments - 2 Insights

Why does the health endpoint show 'UP' even if I add custom logic?

Because the custom health indicator returns Health.up() explicitly as shown in step 3 of the execution_table, overriding default status.

How does Spring know to use my CustomHealthIndicator?

Spring Boot auto-detects @Component beans implementing HealthIndicator, as shown in step 2 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the healthStatus variable after step 3?

A DOWN

B UP

C UNKNOWN

D null

💡 Hint

Check variable_tracker row for healthStatus at After Step 3 column

At which step does the custom health logic become ready?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

See execution_table action describing bean creation

If you remove @Component from CustomHealthIndicator, what changes in the execution?

A Health endpoint returns error

B Health endpoint is disabled

C Health endpoint returns default status without custom details

D Custom details still appear

💡 Hint

Recall how Spring detects beans from step 2 in execution_table and key_moments explanation

Concept Snapshot

Health Endpoint Customization in Spring Boot:
- Create a class implementing HealthIndicator
- Annotate with @Component for auto-detection
- Override health() to return custom Health status
- Spring Boot calls this on /actuator/health
- Response includes custom status and details

Full Transcript

This visual trace shows how Spring Boot starts and enables the health endpoint. A custom health indicator class is created and annotated with @Component so Spring detects it automatically. When the health endpoint is called, Spring invokes the custom health() method, which returns a status UP with a custom detail message. The client receives this customized health response. Variables like healthStatus and healthDetails update accordingly. Key points include how Spring finds the custom bean and how the health status is set explicitly. The quizzes test understanding of these steps and effects of removing annotations.

Practice

1. What is the main purpose of customizing the health endpoint in Spring Boot?

easy

A. To automatically restart the application on failure

B. To change the port number of the application

C. To add specific checks that show detailed app status

D. To disable all health checks

Solution

1. Step 1: Understand the health endpoint role

   The health endpoint shows the app's status and can be extended to include custom checks.

2. Step 2: Identify customization purpose

   Customizing allows adding specific checks to provide detailed status beyond default info.

3. Final Answer:

   To add specific checks that show detailed app status -> Option C

4. Quick Check:

   Health endpoint customization = detailed app status [OK]

Hint: Health endpoint customization means adding detailed status checks [OK]

Common Mistakes:

• Thinking it changes app port
• Assuming it disables health checks
• Believing it restarts app automatically

2. Which interface must you implement to create a custom health check in Spring Boot?

easy

A. HealthIndicator

B. HealthCheck

C. HealthService

D. HealthStatus

Solution

1. Step 1: Recall Spring Boot health customization

   Custom health checks require implementing a specific interface.

2. Step 2: Identify correct interface

   The interface to implement is HealthIndicator, which requires overriding health().

3. Final Answer:

   HealthIndicator -> Option A

4. Quick Check:

   Custom health check interface = HealthIndicator [OK]

Hint: Custom health checks need HealthIndicator interface [OK]

Common Mistakes:

• Using HealthCheck instead of HealthIndicator
• Confusing with HealthService or HealthStatus
• Not overriding health() method

3. Given this custom health indicator code, what will the health endpoint show?

public class MyHealth implements HealthIndicator {
  @Override
  public Health health() {
    return Health.up().withDetail("db", "reachable").build();
  }
}

medium

A. {"status":"UP","details":{"db":"reachable"}}

B. {"status":"DOWN","details":{"db":"reachable"}}

C. {"status":"UP"}

D. {"status":"DOWN"}

Solution

1. Step 1: Analyze health() method return

   The method returns Health.up() with a detail key "db" set to "reachable".

2. Step 2: Understand output format

   The health endpoint shows status "UP" and includes the details map with "db":"reachable".

3. Final Answer:

   {"status":"UP","details":{"db":"reachable"}} -> Option A

4. Quick Check:

   Health.up() with details = status UP plus details [OK]

Hint: Health.up() withDetail adds details and sets status UP [OK]

Common Mistakes:

• Confusing UP with DOWN status
• Ignoring details in output
• Assuming default status without details

4. Identify the error in this custom health indicator code:

public class CustomHealth implements HealthIndicator {
  public Health health() {
    return Health.down().withDetails("error", "Database unreachable").build();
  }
}

medium

A. Method should be annotated with @Override

B. withDetails() method does not exist, should be withDetail()

C. Method name should be checkHealth() instead of health()

D. Health.down() cannot be used in custom indicators

Solution

1. Step 1: Check method signature and annotations

   The method correctly named health() matches interface; @Override annotation is optional but recommended.

2. Step 2: Verify method calls on Health builder

   The method withDetails() does not exist; correct method is withDetail() for adding one detail.

3. Final Answer:

   withDetails() method does not exist, should be withDetail() -> Option B

4. Quick Check:

   Use withDetail() to add single detail [OK]

Hint: Use withDetail() not withDetails() to add details [OK]

Common Mistakes:

• Missing @Override annotation (not error but best practice)
• Wrong method name instead of health()
• Thinking Health.down() is invalid

5. You want to customize the health endpoint to show "UP" only if both database and cache are reachable. Which approach correctly implements this logic?

hard

A. Use two separate HealthIndicator classes without combining results

B. Return Health.up() always and add details for database and cache status

C. Return Health.down() always and ignore individual checks

D. Return Health.up() if both checks pass; else Health.down() with details for each failure

Solution

1. Step 1: Understand combined health logic

   The health status should be UP only if both database and cache are reachable; otherwise DOWN.

2. Step 2: Implement conditional return with details

   Return Health.up() if both pass; else return Health.down() and include details explaining which failed.

3. Final Answer:

   Return Health.up() if both checks pass; else Health.down() with details for each failure -> Option D

4. Quick Check:

   Combined checks control status UP or DOWN with details [OK]

Hint: Return UP only if all checks pass; else DOWN with failure details [OK]

Common Mistakes:

• Returning UP regardless of failures
• Ignoring combined status logic
• Splitting checks without combining results