What changed matters more than the symptom sometimes. I’d make a quick timeline first for Yarrlist:
- Last thing edited before it broke: env vars, reverse proxy, image tag, storage path, auth?
- Test Yarrlist directly on its mapped port, bypassing proxy/CDN/auth middleware.
- Open the app in a private window. Cached JS and stale cookies can make a healthy app look broken.
- Compare current env/config against a known-good backup or the compose you originally intended. A single renamed variable can brick startup behavior without obvious logs.
- Check system time inside the container and host. I disagree a bit with chasing only network errors first. If sessions, tokens, or API validation depend on time, clock drift causes weird login/save failures.
@nachtdromer is right to separate app failure from surrounding stack issues, but I’d also verify browser console errors, not just network responses.
Pros of Yarrlist: lightweight, flexible, easy to self-host.
Cons of Yarrlist: setup can be brittle, updates can expose config mistakes, troubleshooting usually needs logs plus compose.
If you post the exact failure text and redacted config, people can narrow it down fast.