Is this urgent?
No
What parts are affected
Frontend
What is the server version
v0.7.9
What is the client version
v0.7.9
What platform are you using
Linux
What's the problem 🤔
Quick context first: I run KitchenOwl on Freeshard, a self-hosting platform where apps are put to sleep when idle and restarted on demand. So a cold start is totally normal here — you open the app and the containers spin up on the spot, with the web container coming up a few seconds before the backend is ready. That timing is what surfaces this.
Setup: split kitchenowl-web + kitchenowl-backend.
What happens: when I open the app while the backend is still starting, the frontend loads from the service worker cache and immediately redirects to /unreachable. So instead of a "starting up, hang on" screen I just hit the dead-end page and have to reload a few times until the backend is up.
Two flavours of the same thing:
- Backend briefly unreachable during startup → hard redirect to
/unreachable instead of a loading/retry state.
- Right after a version bump, the cached frontend is older than the new backend's
min_frontend_version, so I get "app version is not supported, please update the app" until I hard-refresh (Ctrl+F5) to drop the SW cache.
What I'd expect: when the health check fails transiently (connection refused / timeout), show a loading / "backend starting" state and retry for a bit before falling back to /unreachable. And a stale service-worker cache shouldn't hard-fail on the version check — ideally the SW updates and reloads itself.
tbh the redirect makes cold-starts look broken when they're really just slow. A short retry loop would smooth it over.
Happy to test a fix on my setup.
Share your configuration
networks:
portal:
external: true
services:
kitchenowl:
restart: always
image: tombursch/kitchenowl-web:v0.7.9
container_name: kitchenowl
volumes:
- "{{ fs.app_data }}/data:/data"
environment:
- BACK_URL=kitchenowl-backend:5000
depends_on:
kitchenowl-backend:
condition: service_healthy
networks:
- portal
kitchenowl-backend:
restart: always
image: tombursch/kitchenowl-backend:v0.7.9
container_name: kitchenowl-backend
environment:
- JWT_SECRET_KEY=***
# Backend image ships its own HEALTHCHECK (uwsgi_curl against /api/health/<token>).
# Override only the timing so cold starts gate quickly instead of waiting out the
# image-default 60s interval; the health command + token stay upstream's.
healthcheck:
interval: 5s
timeout: 3s
retries: 12
start_period: 10s
volumes:
- "{{ fs.app_data }}/data:/data"
networks:
- portal
Is this urgent?
No
What parts are affected
Frontend
What is the server version
v0.7.9
What is the client version
v0.7.9
What platform are you using
Linux
What's the problem 🤔
Quick context first: I run KitchenOwl on Freeshard, a self-hosting platform where apps are put to sleep when idle and restarted on demand. So a cold start is totally normal here — you open the app and the containers spin up on the spot, with the web container coming up a few seconds before the backend is ready. That timing is what surfaces this.
Setup: split
kitchenowl-web+kitchenowl-backend.What happens: when I open the app while the backend is still starting, the frontend loads from the service worker cache and immediately redirects to
/unreachable. So instead of a "starting up, hang on" screen I just hit the dead-end page and have to reload a few times until the backend is up.Two flavours of the same thing:
/unreachableinstead of a loading/retry state.min_frontend_version, so I get "app version is not supported, please update the app" until I hard-refresh (Ctrl+F5) to drop the SW cache.What I'd expect: when the health check fails transiently (connection refused / timeout), show a loading / "backend starting" state and retry for a bit before falling back to
/unreachable. And a stale service-worker cache shouldn't hard-fail on the version check — ideally the SW updates and reloads itself.tbh the redirect makes cold-starts look broken when they're really just slow. A short retry loop would smooth it over.
Happy to test a fix on my setup.
Share your configuration