Logs

The Logs page streams Sublarr’s server log into your browser. New lines arrive over WebSocket so you don’t have to refresh, and the last 500 entries are kept in memory for searching and scrolling. When you need to share an issue with maintainers, this is where you copy the relevant lines from.

Layout

The page is one big virtualised log viewer with a toolbar on top. The toolbar’s height is fixed so very long log lines don’t push controls off-screen.

Control	Effect
Level dropdown	Filter to a minimum severity. WARNING hides INFO and DEBUG; ERROR shows only errors. ALL shows everything.
Search box	Substring match (case-insensitive) on the entire log line.
Pause / Resume	Stops live updates so the view doesn’t jump while you read.
Auto-scroll	When enabled (default), the viewport follows new lines. Toggling off lets you scroll up to inspect history.
Download	Saves the currently visible (filtered) lines as a .log file.

Tip

Use Pause + Search when reproducing a bug: pause first, trigger the action, then search for the unique string you expect — the line will be in the buffer even if it scrolled past while you were typing.

Log levels

Sublarr’s logger emits four severities. The “level” you set in Settings → System is the minimum severity written to file; the page filter is independent and only narrows what you see in the browser.

Level	When you’d raise it to
DEBUG	Reproducing a bug — verbose request/response and worker traces.
INFO	Default. Lifecycle events, scheduler ticks, downloads.
WARNING	Production where you only care about deviations from the happy path.
ERROR	Quiet logs — only failures land.

Categories

Sublarr tags each line with a logger name. The viewer doesn’t expose a category filter directly, but the search box does the same job:

Search	Matches
wanted_scanner	Wanted-list scanner ticks and decisions.
translation	Translation pipeline.
apscheduler	Scheduler triggers, missed firings, history writes.
werkzeug	HTTP access log lines.
auth	Login attempts, lockouts, API-key checks.

Download for support

When opening an issue, the most useful artifact is the log around the failing action. The recipe:

1. Set Level to DEBUG and reproduce the issue once.
2. Pause the stream.
3. Use Search to filter to the relevant subsystem (e.g. subdl for a SubDL provider issue).
4. Click Download. The resulting .log already has the irrelevant lines stripped.

Caution

DEBUG logs may contain provider URLs and partial subtitle text. Skim the file before attaching it to a public issue.

Downloading logs over the API

GET /api/v1/logs/download returns an anonymised support bundle as a ZIP. The bundle strips host paths, IP addresses and the hostname, and adds the context a diagnosis needs — version, platform, deployment mode and the top errors.

Pass ?raw=1 to get the plain, unredacted .log file instead. Scripts written against an older build received the raw file from the bare endpoint, so add that parameter if a download suddenly arrives as a ZIP.

Every log file also opens with a line identifying the instance that wrote it — version, platform, whether it runs in a container, the database backend, the deployment mode and the rotation window. It is written again on every rotation, so a rotated file still explains itself.

File on disk

The same lines are appended to SUBLARR_LOG_FILE (default /config/sublarr.log in Docker). The browser viewer reads from the live tail; the on-disk file is the authoritative source if your retention is longer than the in-memory buffer of 500 lines.