feat(ui): warn in the Admin UI when no Redis is configured

[devin-ai-integration]

TLDR

Problem this solves:

• Proxies run multi-worker without Redis and nobody notices
• Rate limits, budgets, cache invalidation then silently work per worker
• No single doc says what Redis is required for

How it solves it:

• Default-on red banner across the Admin UI when no Redis
• Links to a new doc listing everything degraded without Redis
• LITELLM_DISABLE_NO_REDIS_WARNING=true hides it for single-worker setups

User Flow

Before: an admin running the proxy with 4 workers and no Redis sees nothing wrong, while a 100 rpm key actually serves 400 rpm

1. They start the proxy with no Redis in the config and no REDIS_HOST / REDIS_URL, --num_workers 4
2. They open https://litellm-domain/ui/ and every page looks normal
3. They create a key with rpm_limit: 100 and send 400 requests in a minute, all of which succeed

After: the same admin is told on every UI page that Redis is missing, and what that costs them

1. They start the same proxy and open https://litellm-domain/ui/
2. A red banner sits under the header on every page: "No Redis configured. Redis is highly recommended", with a link to https://docs.litellm.ai/docs/proxy/redis_requirements listing what is per worker without Redis
3. They point their config at Redis (a router_settings.redis_host block, a Redis cache_params block, or general_settings.coordination_redis), restart, reload the UI, and the banner is gone
4. An admin who is deliberately on one worker instead sets LITELLM_DISABLE_NO_REDIS_WARNING=true, restarts, and the banner is gone

Relevant issues

Linear ticket

Pre-Submission checklist

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review

Screenshots / Proof of Fix

Before and after screen recording, captured on the base branch at 79d412e and on this branch at 48fa4a0, is in the Slack thread: https://berriaillm.slack.com/archives/C0B302ZJU05/p1786413555538489?thread_ts=1786413555.538489&cid=C0B302ZJU05

UI change, so here is what to run and where to look:

1. Start the proxy with no Redis in the environment: env -u REDIS_HOST -u REDIS_PORT -u REDIS_URL python litellm/proxy/proxy_cli.py --config litellm/proxy/dev_config.yaml --detailed_debug --reload 2>&1 | tee litellm.log
2. curl -s http://localhost:4000/health/readiness/details -H "Authorization: Bearer sk-1234" | jq .show_no_redis_warning should print true
3. npm run dev in ui/litellm-dashboard, open http://localhost:3000/ui/?page=api-keys and expect the red "No Redis configured. Redis is highly recommended" banner under the header, with a working docs link
4. Restart the proxy with router_settings.redis_host / redis_port (or a Redis cache_params block) pointed at docker run -d -p 6379:6379 redis:7, reload the page, and the banner is gone (step 2 now prints false)
5. Restart again with no Redis but LITELLM_DISABLE_NO_REDIS_WARNING=true, reload, and the banner is gone

Type

🆕 New Feature

Caveats (if any)

• Docs page it links to lands in docs(proxy): add a page listing what needs Redis litellm-docs#857
• Banner link 404s until that docs PR merges and deploys
• Bare REDIS_* env vars with no Redis in the config still warn

Link to Devin session: https://app.devin.ai/sessions/c91185109405404bbb87c4967a1346b0
Requested by: @mateo-berri

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[greptile-apps]

Greptile Summary

Adds a proxy readiness flag indicating whether the Admin UI should warn about missing coordination Redis

• Derives the flag from the coordination Redis cache and an opt-out environment variable
• Displays a global dashboard warning with operational impact details and a documentation link
• Adds backend and frontend tests for configured, unconfigured, suppressed, and unavailable states

Confidence Score: 5/5

The PR appears safe to merge with no concrete blocking or non-blocking defects identified

The backend flag safely defaults to warning when Redis is absent, honors explicit suppression, and the shared dashboard query avoids duplicate concurrent requests

Important Files Changed

Filename	Overview
litellm/proxy/health_endpoints/_health_endpoints.py	Adds the Redis-warning decision and exposes it through readiness details without changing readiness status
tests/test_litellm/proxy/health_endpoints/test_health_endpoints.py	Covers Redis presence, suppression values, and both Prisma readiness response branches
ui/litellm-dashboard/src/app/(dashboard)/hooks/healthReadiness/useHealthReadinessDetails.ts	Extends the readiness response interface with the optional warning flag
ui/litellm-dashboard/src/app/(dashboard)/layout.tsx	Mounts the warning in both dashboard shell variants using the existing shared readiness query
ui/litellm-dashboard/src/components/NoRedisWarningBanner.tsx	Renders the warning only when requested by the proxy and provides configuration guidance
ui/litellm-dashboard/src/components/NoRedisWarningBanner.test.tsx	Verifies visibility, documentation link, suppression guidance, and access-token forwarding

_{Reviews (1): Last reviewed commit: "feat(ui): warn in the Admin UI when no R..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[devin-ai-integration]

Verified end to end against a local proxy + Admin UI (feature branch on :4000/:3000, base branch on :4001/:3001).

Before (base branch, no Redis) — no banner:

After (this branch, no Redis) — banner on every page:

Banner disappears with a Redis cache configured (show_no_redis_warning: false):

…and with LITELLM_DISABLE_NO_REDIS_WARNING=true:

Testing also caught that router_settings.redis_host alone (no cache block) left the banner up even though the router does have Redis; the latest commit counts the router's Redis cache as configured. Docs live at BerriAI/litellm-docs#857 — the banner link 404s until that merges and the site redeploys.

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_no_redis_warning_banner (e06d103) with litellm_internal_staging (422d925)}

[mateo-berri]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 48fa4a0. Configure here.}

[ryan-crabbe-berri]

remove this file, unnecessary

[devin-ai-integration]

Removed in e06d103