Jellyseerr Unhealthy or Restarting? It's Probably Not Jellyseerr

Your VPN blips for a few seconds and suddenly Jellyseerr (or Seerr), Notifiarr, SABnzbd, and even apps that never touch the VPN all flip to "restarting" or "unhealthy" at the same time, with logs that show nothing wrong. That pattern almost always means a VPN health check is triggering a stack-wide restart, not that any of those apps actually crashed.

Rather not untangle dependency chains by hand? SparkBox only restarts the containers that actually ride the VPN when it flickers, so Jellyseerr, Notifiarr, and everything else stays up. See the walkthrough →

Why Jellyseerr shows "unhealthy" with completely clean logs

When a container's status shows "restarting" or "unhealthy" but its own logs don't show an error, the app itself usually isn't the problem. Something outside the container — an orchestrator, a health-check dependency, or a watchdog script — is deciding to kill and restart it. Jellyseerr has no reason to crash on its own just because a VPN connection somewhere else on the box flickered for a moment. If it's genuinely crash-looping with real errors in its logs, that's a different problem than the one this guide covers.

The giveaway is the pattern: multiple unrelated apps (a request manager, a notification tool, a download client, sometimes even a file-sync app) all flip status at the exact same moment. That's not four separate apps failing independently — that's one trigger event causing a cascade.

Cause 1: Everything is chained to the VPN container's health check

Many self-hosted media stacks route torrent or usenet traffic through a VPN container, and other services connect to it using something like network_mode: "service:vpn" or a depends_on entry with a health condition. That's correct for the apps that genuinely need the VPN's network — but it's common for compose files to accidentally wire in apps that don't need it at all, like a request manager or a dashboard, either by copy-pasting a working block or by grouping "the whole media stack" under one dependency umbrella.

When the VPN container briefly reports unhealthy (even for a few seconds), anything depending on its health status gets restarted too, whether or not it actually uses the tunnel.

1. Open your compose file (or your panel's per-container network settings) and find every service that references the VPN container's network or health status.
2. For each one, ask: does this app's traffic actually need to go through the VPN? A request manager, a notification service, or a dashboard almost never does.
3. Remove the VPN dependency from anything that doesn't need it, so it runs on its normal network and isn't tied to the VPN's health at all.
4. Keep the dependency only on the download client(s) that are meant to be VPN-routed.

Cause 2: A watchdog script or autoheal container is too broad

Some setups run a small watchdog container (sometimes called an autoheal or health-check watcher) that scans for any container marked unhealthy and restarts it. That's useful in principle, but if it's scoped to "every container in this project" rather than "just the containers that legitimately depend on the VPN," it will happily restart Jellyseerr, Notifiarr, and SABnzbd the moment the VPN's status flickers, even though none of them are actually broken.

1. Check whether you're running any watchdog/autoheal container alongside your stack.
2. Look at what it's configured to watch — a wildcard or "all containers" setting is the usual culprit.
3. Scope it down to only the containers that should be restarted on VPN status changes, or remove non-VPN apps from its target list entirely.

Cause 3: The VPN health check itself is too twitchy

A VPN container's health check typically pings or curls out to confirm the tunnel is actually routing traffic. If that check has a short timeout, a low retry count, or no grace period, a single dropped packet or a momentary DNS hiccup can flip the container to unhealthy for a few seconds even though the tunnel recovers on its own almost immediately. That single flicker is often all it takes to trigger the cascade described above.

1. Check your VPN container's health check settings — interval, timeout, and retries.
2. Loosen them slightly (a couple more retries, a longer interval) so a one-off blip doesn't immediately flip the status.
3. If your VPN provider itself is dropping connections frequently, that's worth investigating separately, but most flickers of a second or two are normal network noise and shouldn't require any downstream restarts at all.

Verifying the fix

1. Watch your container statuses over a normal day rather than forcing a VPN disconnect — the goal is to see what happens on a real, ordinary flicker.
2. Confirm that only the containers actually routed through the VPN restart when its status changes.
3. Confirm Jellyseerr, Notifiarr, SABnzbd (if it's not VPN-routed in your setup), and anything else unrelated stay untouched and simply keep running.
4. If everything else stays stable, the cascade is fixed. If something is still restarting alongside the VPN, it's still chained to it somewhere you haven't found yet.

A different problem people confuse with this one: Homarr hitting a memory ceiling

If your dashboard app (commonly Homarr) is the one that keeps crashing, it's worth separating that out from the VPN issue above — it's a different root cause. Homarr has a known upstream memory leak that causes it to slowly climb in memory usage until it hits its container's memory limit and gets killed. That's not a VPN flicker, and it's not a stale board setting either, despite how it might look from the outside.

1. Check the container's memory usage over time — a steady climb toward the limit, rather than a sudden spike, points to the known leak rather than a one-off crash.
2. Give the container more memory headroom if your hardware allows it, which buys time between restarts.
3. Keep an eye on Homarr's releases for a fix, since this is an upstream issue rather than something you can permanently patch in your own config.

Frequently asked

Why does Jellyseerr say unhealthy when I didn't change anything?

Most of the time it's not Jellyseerr at all. If your VPN container briefly loses connection, a lot of setups are wired so that a VPN health blip restarts the entire stack, not just the containers that actually route through the VPN. Jellyseerr gets caught in the crossfire and looks like it's crash-looping even though its logs are perfectly clean.

Is it normal for SABnzbd or Notifiarr to restart when the VPN reconnects?

SABnzbd can make sense if it's meant to route traffic through the VPN, but Notifiarr, dashboards, and anything that never touches the tunnel shouldn't restart just because the VPN blipped. If they do, your dependency chain or watchdog script is scoped too broadly.

Why does Homarr keep crashing even after I fix the VPN restart issue?

That's a separate, known issue: Homarr has an upstream memory leak that causes it to hit its memory ceiling and get killed. It's not related to VPN flickers or stale board settings, and the fix is to give it more memory headroom or watch for an upstream release that patches the leak.

Does an unhealthy VPN container mean my VPN provider is broken?

Not necessarily. A short connectivity blip, a DNS hiccup, or a health check that's too strict can all mark the VPN container unhealthy for a few seconds without your VPN actually being down. The real problem is usually how aggressively other containers react to that status, not the VPN connection itself.