[GH-ISSUE #24111] feat: Provider failover status indicator per model with last-switch timestamp #35720

New Issue

GiteaMirror · 2026-04-25T09:53:47-05:00

GiteaMirror commented

2026-04-25 09:53:47 -05:00

Originally created by @githb-ac on GitHub (Apr 24, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24111

Check Existing Issues

I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

When a model is configured with multiple provider endpoints in Open WebUI, there
is no visibility into which provider is currently active for a given model, whether
a failover has occurred, or when it last happened. Users running provider-agnostic
setups (e.g. same model hosted on OpenRouter, SiliconFlow, and DeepInfra) have no
way to know if their primary provider went down and a fallback is now serving
requests, without checking provider dashboards externally.

Desired Solution you'd like

Add a provider failover status indicator in Admin → Models showing per model:

Currently active provider (e.g. "SiliconFlow ✓ Active")
Failover status — whether the model is on its primary or a fallback provider
Timestamp of last provider switch (e.g. "Switched 2h ago")
Visual indicator: green for primary active, amber for running on fallback
Optional: a manual override button to force-switch back to primary provider

Alternatives Considered

Currently the only way to detect a failover is to notice degraded response quality
or check each provider's status page individually. There is no in-UI indication
that a model has silently switched to a fallback provider.

Additional Context

A working visual prototype showing the provider status layout is attached.

owui-chart-cost-provider.html

Originally created by @githb-ac on GitHub (Apr 24, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24111 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description When a model is configured with multiple provider endpoints in Open WebUI, there is no visibility into which provider is currently active for a given model, whether a failover has occurred, or when it last happened. Users running provider-agnostic setups (e.g. same model hosted on OpenRouter, SiliconFlow, and DeepInfra) have no way to know if their primary provider went down and a fallback is now serving requests, without checking provider dashboards externally. ### Desired Solution you'd like Add a provider failover status indicator in Admin → Models showing per model: - Currently active provider (e.g. "SiliconFlow ✓ Active") - Failover status — whether the model is on its primary or a fallback provider - Timestamp of last provider switch (e.g. "Switched 2h ago") - Visual indicator: green for primary active, amber for running on fallback - Optional: a manual override button to force-switch back to primary provider ### Alternatives Considered Currently the only way to detect a failover is to notice degraded response quality or check each provider's status page individually. There is no in-UI indication that a model has silently switched to a fallback provider. ### Additional Context A working visual prototype showing the provider status layout is attached. [owui-chart-cost-provider.html](https://github.com/user-attachments/files/27065916/owui-chart-cost-provider.html)

GiteaMirror commented

2026-04-25 09:53:48 -05:00

@Classic298 commented on GitHub (Apr 25, 2026):

You can use filters for that

@Classic298 commented on GitHub (Apr 25, 2026): You can use filters for that

GiteaMirror commented

2026-04-25 09:53:49 -05:00

@githb-ac commented on GitHub (Apr 25, 2026):

Thanks for the response — but filters in Open WebUI are for narrowing down chat history and search results. They have no access to which provider endpoint is currently serving a given model, whether a failover has occurred, or when the last provider switch happened.

What's being requested is a live status indicator in Admin → Models showing per-model provider health — primary vs fallback, with a last-switched timestamp. This requires Open WebUI to track which provider endpoint responded last for each model. That information does not exist anywhere in the current UI and cannot be surfaced with filters. Would appreciate reconsideration.

@githb-ac commented on GitHub (Apr 25, 2026): Thanks for the response — but filters in Open WebUI are for narrowing down chat history and search results. They have no access to which provider endpoint is currently serving a given model, whether a failover has occurred, or when the last provider switch happened. What's being requested is a live status indicator in Admin → Models showing per-model provider health — primary vs fallback, with a last-switched timestamp. This requires Open WebUI to track which provider endpoint responded last for each model. That information does not exist anywhere in the current UI and cannot be surfaced with filters. Would appreciate reconsideration.

GiteaMirror commented

2026-04-25 09:53:49 -05:00

@Classic298 commented on GitHub (Apr 25, 2026):

Filters can very much emit status information and have access to routing information as long as it's returned by the provider and can show it in the chat read up on the different kinds of event emitters they very much can do what you want :)

@Classic298 commented on GitHub (Apr 25, 2026): Filters can very much emit status information and have access to routing information as long as it's returned by the provider and can show it in the chat read up on the different kinds of event emitters they very much can do what you want :)

GiteaMirror commented

2026-04-25 09:53:49 -05:00

@githb-ac commented on GitHub (Apr 25, 2026):

Event emitters in filters fire during an active chat request — they can surface information about that specific request as it happens. They cannot maintain a persistent record of which provider endpoint last responded for each model, track when a failover occurred, or display that history in Admin → Models outside of a chat session.

What's being requested is a persistent status indicator in the admin panel — not a per-request chat notification. The data doesn't exist in Open WebUI at all today because the system doesn't log which provider served which request at the model level. An event emitter can't surface data that was never stored. Could you point to where this routing history is currently persisted so I can understand what you're referring to?

@githb-ac commented on GitHub (Apr 25, 2026): Event emitters in filters fire during an active chat request — they can surface information about that specific request as it happens. They cannot maintain a persistent record of which provider endpoint last responded for each model, track when a failover occurred, or display that history in Admin → Models outside of a chat session. What's being requested is a persistent status indicator in the admin panel — not a per-request chat notification. The data doesn't exist in Open WebUI at all today because the system doesn't log which provider served which request at the model level. An event emitter can't surface data that was never stored. Could you point to where this routing history is currently persisted so I can understand what you're referring to?

GiteaMirror commented

2026-04-25 09:53:50 -05:00

@Classic298 commented on GitHub (Apr 25, 2026):

Yes they can as the event emitter status event is being persistent into the chat itself and attached to that message and you can always see it in the chat.

It literally solves your usecase

@Classic298 commented on GitHub (Apr 25, 2026): Yes they can as the event emitter status event is being persistent into the chat itself and attached to that message and you can always see it in the chat. It literally solves your usecase

GiteaMirror commented

2026-04-25 09:53:51 -05:00

@githb-ac commented on GitHub (Apr 25, 2026):

Event emitters in filters fire during an active chat request — they can surface information about that specific request as it happens. They cannot maintain a persistent record of which provider endpoint last responded for each model, track when a failover occurred, or display that history in Admin → Models outside of a chat session.

What's being requested is a persistent status indicator in the admin panel — not a per-request chat notification. The data doesn't exist in Open WebUI at all today because the system doesn't log which provider served which request at the model level. An event emitter can't surface data that was never stored. Could you point to where this routing history is currently persisted so I can understand what you're referring to?

@githb-ac commented on GitHub (Apr 25, 2026): Event emitters in filters fire during an active chat request — they can surface information about that specific request as it happens. They cannot maintain a persistent record of which provider endpoint last responded for each model, track when a failover occurred, or display that history in Admin → Models outside of a chat session. What's being requested is a persistent status indicator in the admin panel — not a per-request chat notification. The data doesn't exist in Open WebUI at all today because the system doesn't log which provider served which request at the model level. An event emitter can't surface data that was never stored. Could you point to where this routing history is currently persisted so I can understand what you're referring to?

GiteaMirror commented

2026-04-25 09:53:51 -05:00

@Classic298 commented on GitHub (Apr 25, 2026):

Yes they can maintain a persistent record. Look into event emitter in the docs

@Classic298 commented on GitHub (Apr 25, 2026): Yes they can maintain a persistent record. Look into event emitter in the docs

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#35720