[Bug] Whisper-WebUI readiness probe downloads the full 482 KB Gradio page every 3s (constant idle CPU + network)

[RonnyPfannschmidt]

Summary

The Whisper-WebUI app's readiness probe fetches the full Gradio index page (≈482 KB) every 3 seconds, forever. On an otherwise idle Olares this produces a constant ~160 KB/s of internal network traffic and keeps the Whisper backend at a constant ~6% CPU re-rendering the page, which contributes to the device never cooling down / fans never stopping overnight.

Observed on Olares 1.12.6-rc.2 (Olares One), app whisperwebuiv2 (image beclab/harveyff-whisper-webui:v1.0.7). The same probe ships in whisperwebuiv3.

Root cause

The probe on the openresty client-proxy container:

• v2: whisperwebuiv2/whisperwebuiv2/templates/clientproxy.yaml L181–L193
• v3: whisperwebuiv3/templates/whisperwebuiv3.yaml L246–L256

readinessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - |
        http_code=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8080)
        [ $http_code -ge 200 ] && [ $http_code -lt 500 ]
  initialDelaySeconds: 2
  timeoutSeconds: 3
  periodSeconds: 3
  successThreshold: 1
  failureThreshold: 60

curl -o /dev/null discards the body but still downloads it. openresty proxies GET / to the Gradio backend in the whisperwebuiv2server-shared namespace, so every 3 s:

1. Gradio renders the complete UI page (~482 KB) — measurable CPU on the backend (whisper_openai_api.py sits at a constant ~6% CPU on the host while completely idle, ~76 CPU-minutes/day);
2. the page crosses the pod network from the server namespace to the client-proxy pod (~160 KB/s sustained, ~13 GB/day of internal traffic).

Evidence

Client-proxy nginx access log — one entry every 3 s, around the clock, 127.0.0.1 (the probe) is the only client:

127.0.0.1 - - [30/Jul/2026:04:11:59 +0000] "GET / HTTP/1.1" 200 482429 "-" "curl/7.88.1"
127.0.0.1 - - [30/Jul/2026:04:12:02 +0000] "GET / HTTP/1.1" 200 482429 "-" "curl/7.88.1"
127.0.0.1 - - [30/Jul/2026:04:12:05 +0000] "GET / HTTP/1.1" 200 482429 "-" "curl/7.88.1"

Dashboard shows the app receiving ~200 KB/s "network in" while nobody is using it.

Suggested fix

Any of these removes ~all of the idle load while keeping the readiness signal:

• probe with HEAD instead of GET (curl -s -o /dev/null -I -w "%{http_code}" http://localhost:8080) — Gradio answers HEAD without streaming the page body, or
• probe a lightweight endpoint that doesn't render the UI, e.g. Gradio's /gradio_api/heartbeat (or an nginx stub_status/static location that only proves the proxy chain is up), and/or
• relax periodSeconds from 3 to something like 15–30 once the app is up (the tight 3 s period × failureThreshold: 60 looks like it was tuned for fast startup detection; a separate startupProbe would cover that).

Happy to open a PR if a maintainer confirms which direction is preferred.

[TShentu]

Hi @RonnyPfannschmidt

Thank you for the detailed report and suggested fixes. The diagnosis was spot on, and it helped us prioritize this.
This issue is fixed in the latest update: #3374

What we changed, based on your suggestions:

Stop probing the Gradio homepage
The client-proxy no longer does curl GET / every few seconds. That path was forcing Gradio to re-render the full ~482 KB UI and was the source of the idle CPU / internal traffic you measured.

Lightweight readiness endpoint
We added an nginx-only path /__entrance_ready:

while models are still downloading → return 200 so the downloader UI stays reachable;
once models are ready → check Gradio /gradio_api/info (not the HTML homepage).
We evaluated HEAD / and /gradio_api/heartbeat as you suggested; for this chart the dedicated entrance probe was the cleanest way to keep download UX + true Gradio readiness without pulling the homepage.

Separate startup vs steady-state probes (as you recommended)

startupProbe: httpGet /__entrance_ready, periodSeconds: 3, failureThreshold: 60 (fast cold-start detection)
readinessProbe: same path, periodSeconds: 15 (relaxed once up)
We’ve finished verification in our test environment: kube-probe only hits /__entrance_ready with ~13-byte responses, and there are no more probe-driven GET / homepage fetches. Real browser traffic to / is unchanged. We plan to roll this out to production later today.

Thanks again for the clear evidence and the practical fix options — this was exactly the kind of feedback that makes the idle behavior better on Olares One overnight.