8 views
-/https://github.com/berriai/litellm/issues/31851
GitHub · issue

#31851 [Bug]: Public model_hub_table health status does not match Admin UI / background health check cache

  • State: open
  • Author: @freinold
  • Labels: bug, ui-dashboard

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

**Expected:** When `background_health_checks` and `use_shared_health_check` are enabled, the public `model_hub_table` (`/ui/model_hub`) should display the same runtime health status shown in the Admin UI Dashboard (i.e. the Redis-backed background health check cache). If a model endpoint is actually failing, the public hub should show `unhealthy`.

**Actual:** The public `model_hub_table` displays a static/config-backed health status that does not reflect the background health check results. For the same failing model, the Admin UI correctly shows `unhealthy` (via `/health/shared-status`), while the public hub continues to show `healthy` or `unknown` sourced from `litellm_modeltable` / static config metadata.

**Configuration context:** ```yaml general_settings: background_health_checks: true use_shared_health_check: true health_check_interval: 3600 ```

This was nominally addressed in #19034, but the implementation appears to read health from the wrong data layer.

### Steps to Reproduce

1. Configure a model with a deliberately broken/…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (4 events)
#0 of 0 · 31d18h58m59s ago — entered · #import:https:::github.com:berriai:litellm post #1894
The right issue is harder because it requires correcting span lifecycle semantics while preserving parentage, processor behavior, and compatibility across telemetry integrations, with subtle regression risk. The left issue is comparatively contained to aligning an existing UI endpoint with the shared health-status data source.
The left requires deeper investigation of aggregation semantics, query paths, and regression validation across multiple export modes, while the right is comparatively localized source-selection and status wiring with focused tests.
#31851 is harder because it spans proxy data access, shared health-check caching, public API behavior, and dashboard consistency, with greater regression and integration-testing risk. #28239 is comparatively localized to parameter validation/serialization and provider-specific request handling.
#0 of 0 · 31d18h7m20s ago — current · #import:https:::github.com:berriai:litellm post #2743
Multi-credential routing requires coordinated registry, selection, cooldown, retry, failover, configuration, and compatibility changes across proxy request paths, with substantial concurrency and edge-case risk. The health-status issue is comparatively narrower: identify the authoritative cache and align one public presentation layer with it, followed by focused regression tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search