Check server health

Silo is in active development before 1.0. These guides are updated frequently.

Start with the task that failed and when it failed. “The server is down” can mean a stopped container, an unavailable database, or one media file that cannot play.

Check startup

For the default Docker installation, run these on the Docker host:

docker compose ps
docker compose logs --tail 100 silo
curl --fail http://localhost:8090/api/v1/health
curl --fail http://localhost:8090/api/v1/ready

From another machine, replace localhost with the server’s address.

/api/v1/health answers as soon as Silo’s web server is running. The container’s own health check uses it, so docker compose ps can show Silo as unhealthy during a long database migration at startup. Check the logs before restarting it.

/api/v1/ready also checks PostgreSQL and storage:

Response	Meaning
HTTP 200, {"status":"ok"}	Ready
HTTP 200, "status":"degraded"	Artwork or S3 storage failed its check. The body shows which: "s3":false or "artwork":false. Silo keeps serving, but images may be missing.
HTTP 503, "status":"error"	Silo cannot reach PostgreSQL
HTTP 503, "status":"shutting_down"	Silo is stopping. It keeps serving for SILO_SHUTDOWN_DELAY, 5 seconds by default, so a load balancer can send new requests elsewhere first. See Nodes and stop timeouts.

A degraded answer still returns HTTP 200, so read the body. Readiness doesn’t check Redis or playback.

A scan is stuck or empty

Open Admin > Libraries and check the active scan and reported errors. Make sure the media disk is mounted and the container can read the library folder.

If a scan finds no files, fix the path before you confirm any cleanup or delete anything. See library troubleshooting.

Playback fails

Try one known file and note the client, the time, and the audio and subtitle tracks you chose. Then:

1. Open Admin > Activity while the file plays. A converted stream shows its encoder, such as HW VAAPI or SW for software.
2. On a single server, open Admin > Playback > Settings. The line under Hardware acceleration, in the Transcoding group, shows the detected hardware, or No supported graphics hardware found. The admin dashboard shows the server’s CPU, memory, and disk use.
3. With separate nodes, open Admin > Playback > Nodes and check the node’s state, Acceleration, Load, and Capacity. Read node status explains each reading. A single server has no entries here.

Make sure the server or node can read the file and has free space for transcodes. If only remote clients fail, check external access. If only converted streams fail, check transcoding.

If remote playback is slow

If viewers away from home get much less than their connection supports, check what Silo’s TCP tuning applied when it started. Open Admin > Logs > Server Log, set Component to tcpcongestion, and look at the entries from the last start:

• tcp congestion control: listener state appears once for each port Silo serves viewers on. A warning means the kernel didn’t give that port BBR.
• tcp buffer limits: kernel state shows the kernel’s send limit. It’s always informational, even when the limit is low.
• tcp send buffer: listener state appears once for each port and says whether Silo forced a larger send buffer. A warning means the limit is low and Silo couldn’t raise it, usually because it doesn’t have the NET_ADMIN capability.

Each warning includes what to change, such as loading tcp_bbr on the host or raising net.ipv4.tcp_wmem. Set Component to netadmin to see the net admin: capability state entry. It says whether Silo had NET_ADMIN at startup, and warns if the helper didn’t start or Silo couldn’t confirm that it dropped the capability. None of these warnings stops Silo.

If the entries show no warnings, check whether a reverse proxy or other hop sits between viewers and Silo, because the tuning covers only the connection that ends at Silo.

Background work fails

Open Admin > Server > Scheduled Tasks to find the task and Admin > Logs > Server Log for its error. Repeated provider failures usually mean a rejected key, a rate limit, or a service that can’t be reached. Fix that before retrying tasks; retrying everything at once only adds load.

Disk space

Watch free space for the database and artwork as well as transcodes. A full disk can break one task before the whole server stops responding.

If Silo is slow or uses too much memory

If you collect Prometheus metrics, When an alert fires lists what to check for each alert, such as CPU throttling, growing memory, or a full database pool. If a maintainer asks for more detail, collect a performance profile.

For logs, see Logs and monitoring. Share only a short, checked excerpt when reporting a problem.