feat(#5352): healthgroups endpoint by ulischulte · Pull Request #5416 · codecentric/spring-boot-admin

ulischulte · 2026-06-05T14:58:10Z

Closes #5352:

Added caching and a dedicated REST endpoint for health groups.

When SBA polls an application's /health endpoint, the response may include a groups field (e.g., ["liveness", "readiness"]). Previously this data was fetched on-the-fly from the client. Now:

HealthGroupsCache — A ConcurrentHashMap-based cache stores health groups per instance, updated automatically during each health status poll.
GET /instances/{id}/health-groups — A new REST endpoint serves the cached groups directly, avoiding repeated calls to client applications.
HealthGroupsCacheCleanupTrigger — Listens for InstanceDeregisteredEvent and evicts stale cache entries to prevent memory leaks.
UI integration — The health details view (details-health.vue) now calls the new server-side endpoint instead of fetching groups from the client's health response.

Key design decisions

Cache is populated as a side effect of the existing StatusUpdater health polling (no extra HTTP calls)
Thread-safe via ConcurrentHashMap + List.copyOf() for immutable snapshots
Backward-compatible: the protected convertStatusInfo(ClientResponse) API in StatusUpdater is preserved for subclasses
@ConditionalOnMissingBean on all new beans allows customization

cdprete · 2026-06-06T18:22:01Z

+ * specific data in {@link HealthGroupsCache} on receiving an
+ * {@link InstanceDeregisteredEvent}.
+ */
+public class HealthGroupsCacheCleanupTrigger extends AbstractEventHandler<InstanceDeregisteredEvent> {


This seems a bit an overkill to me.

It would be enough to invoke the deletion in the StatusUpdater with a doOnNext as it's already done to persist the groups (actually, it's enough to add an if there to check the event type and either call the save or the delete method).
We're scheduling a thread to constantly check for a single even type, which barely happens, where the StatusUpdater is already handling all of them anyway.

StatusUpdater polls the /health endpoint — it does not receive InstanceDeregisteredEvent. A deregistered instance simply stops being polled (doUpdateStatus returns early if !instance.isRegistered()), so eviction would never fire there.

I'll investigate a little further and probably will either
(a) keep a lightweight event subscription but reuse an existing handler/scheduler, or
(b) accept the small overhead since cleanup-on-deregister is the established pattern in SBA

StatusUpdater polls the /health endpoint — it does not receive InstanceDeregisteredEvent.

Indeed. For a moment I had the impression it's handled there because the journal view shows all of them.

I'll investigate a little further and probably will either
(a) keep a lightweight event subscription but reuse an existing handler/scheduler, or
(b) accept the small overhead since cleanup-on-deregister is the established pattern in SBA

Wouldn't be enough to have a Spring Boot's @EventListener for the specific application event and remove the entry from the cache when it's received?

cdprete · 2026-06-06T18:35:08Z


  describe('SSE reactive updates', () => {
-    it('should call fetchHealth once on mount, not on SSE version changes', async () => {
+    it('should call fetchCachedHealthGroups once on mount, not on SSE version changes', async () => {


Actually I think we should call the fetchHealthGroups when an SSE is received now, otherwise stale data may be potentially used.

This comment is not specifically related to this test case, but it's a more general statement.

Good catch, and agreed in principle. The current else branch only invalidates the per-group details (group.data = null) but keeps the previously fetched group list, so a group added/removed at runtime would indeed show stale entries until the instance id changes or the view is remounted (although this seems to be an edge case).

I'll update onInstanceChanged so the same-instance branch also calls fetchHealthGroups() (which already resets healthGroupOpenStatus/healthGroupLoadingMap and clears stale data), making the displayed group list self-correcting on SSE updates.

Yep.
Also because, from @SteKoe in a previous PR about a Thymeleaf fix, I discovered that the configuration properties can be changed at runtime from SBA.

Probably, to cover this case as well, we would need SSE also for the health groups, but I don't know how much worthy it really is. Unless a STATUS_CHANGED even is also created when the health response body changes in general and not just by the status (UP, DOWN and so on).
Performance and code clearity wise, it would then indeed be better to update the model of the instance to also have the health groups in it.

cdprete · 2026-06-12T09:30:32Z

+			this.cache.remove(instanceId);
+		}
+		else {
+			this.cache.put(instanceId, List.copyOf(groups));


I think we should ensure that groups are unique, either here by using a LinkedHashSet instead of a List or in the UI to avoid potentially duplicated entries.

cdprete · 2026-06-17T16:00:59Z

-        if (Array.isArray(res.data.groups)) {
-          this.healthGroups = res.data.groups.map((name: string) => ({
+        if (Array.isArray(res.data)) {
+          this.healthGroups = res.data.map((name: string) => ({


Hi @ulischulte.

Will this assignment trigger a UI re-rendering?
If it's so, we should maybe check the content of the response first and set the new state (health groups + reset of state of the accorditions) only if there is indeed a change in the collection of the returned group names.
Otherwise, on every fetch, we'll be re-rendering the UI for nothing if nothing really has changed in the context of the health groups.

Yes, it will trigger a re-rendering of UI. I will add a check to prevent this in terms of UX, as it will also reset the collapsed state. Changing groups in backend will not happen that often, though.

Changing groups in backend will not happen that often, though.

I was wondering exactly because their update will be very rare.

# Conflicts: # spring-boot-admin-server/src/test/java/de/codecentric/boot/admin/server/services/StatusUpdaterTest.java

…in/server/services/StatusUpdater.java Co-authored-by: Cosimo Damiano Prete <8491864+cdprete@users.noreply.github.com>

cdprete · 2026-06-20T14:47:25Z

Hi @ulischulte.

What do you think about the idea of adding a metadata boolean property that the applications under monitoring can populate to indicate if they use health groups or not?
In this way, the additional HTTP call can be avoided if we already know in advance that a particular application is anyway not exposing (or not willing to expose) any health group.
If the property is missing, then we default it to true and we try to fetch the health groups anyway.

Moreover, another optimization (to be verified if it's indeed possible; for now it's just an idea) would be to not just return the group names, but the name of the health indicators they include as well. For example: my-group: [db, ldap].
In this way, in the UI, their health can be shown directly - since we already have the health of the single health indicators available as part of the status update event - without having to fetch it explicitly.

I'm still in favour of adding them to the STATUS_UPDATED event, to be honest - especially after the changes done for #5450 - but so be it :)

cdprete · 2026-06-20T18:48:32Z

-        this.healthGroupLoadingMap = {};
      }
+      // Re-fetch the (server-cached) group list on every instance change
+      this.fetchHealthGroups();


We should do this only if the instance has changed in some meaningful way regarding its status, which means to not do it if the event that gets sent is INFO_UPDATED.

If the process InfoContributor is enabled, the data returned by https://docs.spring.io/spring-boot/api/rest/actuator/info.html changes on every poll, which would mean we're re-fetching the health groups over and over for no real reason.

ulischulte marked this pull request as ready for review June 5, 2026 15:18

ulischulte requested a review from a team as a code owner June 5, 2026 15:18

cdprete reviewed Jun 6, 2026

View reviewed changes

Comment thread ...-admin-server/src/main/java/de/codecentric/boot/admin/server/services/HealthGroupsCache.java Outdated

cdprete reviewed Jun 6, 2026

View reviewed changes

Comment thread ...boot-admin-server/src/main/java/de/codecentric/boot/admin/server/services/StatusUpdater.java Outdated

cdprete reviewed Jun 6, 2026

View reviewed changes

SteKoe changed the title ~~Feature/5352 healthgroups endpoint~~ feat(#5352): healthgroups endpoint Jun 12, 2026

cdprete reviewed Jun 12, 2026

View reviewed changes

cdprete reviewed Jun 17, 2026

View reviewed changes

ulischulte and others added 6 commits June 19, 2026 12:06

#5352: Cache health groups and expose via health-groups endpoint

537eeee

# Conflicts: # spring-boot-admin-server/src/test/java/de/codecentric/boot/admin/server/services/StatusUpdaterTest.java

#5352: Cleanup health groups cache

c0c3dbf

Update spring-boot-admin-server/src/main/java/de/codecentric/boot/adm…

58d8efd

…in/server/services/StatusUpdater.java Co-authored-by: Cosimo Damiano Prete <8491864+cdprete@users.noreply.github.com>

Fix renaming of method

e0a1510

#5352: Define interface for HealthGroupsCache

95f761b

#5352: Re-fetch the (server-cached) group list on every instance change

ffe3250

SteKoe force-pushed the feature/5352-healthgroups-endpoint branch from fa4bcf7 to ffe3250 Compare June 19, 2026 10:07

cdprete reviewed Jun 20, 2026

View reviewed changes

Conversation

ulischulte commented Jun 5, 2026

Uh oh!

Uh oh!

cdprete Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ulischulte Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

cdprete Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cdprete Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ulischulte Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

cdprete Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cdprete Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

cdprete Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteKoe Jun 19, 2026

Choose a reason for hiding this comment

Uh oh!

cdprete Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cdprete commented Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cdprete Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cdprete Jun 6, 2026 •

edited

Loading

cdprete Jun 12, 2026 •

edited

Loading

cdprete Jun 6, 2026 •

edited

Loading

cdprete Jun 12, 2026 •

edited

Loading

cdprete Jun 17, 2026 •

edited

Loading

cdprete Jun 20, 2026 •

edited

Loading

cdprete commented Jun 20, 2026 •

edited

Loading

cdprete Jun 20, 2026 •

edited

Loading