Skip to content

Settings — Diagnostics

The Diagnostics page runs Sublarr’s full battery of self-checks and presents the result in one scannable view. Open it before filing a bug, after an upgrade, or whenever the dashboard’s health indicator goes amber. The checks are the same ones the /api/v1/health endpoint runs — Diagnostics just renders them with helpful context.

Each row is one check. Categories group related checks:

CategoryChecks
CoreDatabase connection, migrations applied, scheduler running, log file writable.
StorageMedia path mounted + readable, config dir writable, disk free above warning threshold, trash dir writable.
ConnectionsEach *arr instance reachable, each media server reachable.
ProvidersEach enabled provider’s last test result.
TranslationEach enabled translation backend’s last test result.
ExternalInternet reachable, AniDB cache fresh, TMDB / TVDB reachable.
FieldEffect
NameWhat’s being checked.
StatusOK / warning / failed.
LatencyTime the check took.
Last runTimestamp.
DetailHuman-readable result (e.g. “Reachable, auth OK, 8 series indexed”).
Re-runForce the check immediately.

The Run full self-test button at the top runs all checks in parallel and reports the result. Use it as the first thing in any troubleshooting session — most problems surface here.

Self-test stepWhat it tries
Smoke test APIHit every public API endpoint with a valid auth header; verify 2xx.
Smoke test schedulerConfirm the scheduler is alive and processed at least one job in the last 24h.
Smoke test databaseRun a representative query (recent activity rows).
Smoke test sample providerRound-trip the highest-priority enabled provider.
Smoke test translationIf translation is enabled, dry-run the configured backend.
FieldReads
Sublarr versionThe shipped semver.
Build SHAGit commit.
Built atImage build timestamp.
PythonInterpreter version.
DatabaseDriver + version (sqlite 3.42.0 / postgresql 14.x).
RedisURL + version, or “not configured”.
Bundled binariesffmpeg, mkvmerge, ffprobe, ffsubsync, alass versions.

These are exactly the fields maintainers ask for in bug reports — copy the block to GitHub issues.

The Export current config button produces a sanitised YAML dump of every UI setting. Secrets are masked (api_key: ***); structure is preserved. Useful for:

  • Sharing your setup when asking for help.
  • Diffing two installs to spot drift.
  • Capturing config before a major change.

The Open logs button opens the Logs page filtered to the last 5 minutes. Useful for “I just clicked the failing thing — show me the log line that came out”.

SymptomWhat Diagnostics shows
Scheduler stalledscheduler_alive: failed plus the last successful firing’s age.
Provider auto-disabledThe provider’s row turns red with the auto-disable reason.
Translation backend offlineThe backend’s row reports the upstream error message.
Disk filling upStorage row shows percentage with amber/red coloring.
Database migration pendingCore row shows migrations: pending; the action button runs the migration.

Below the health grid is a small metrics panel — the same Prometheus metrics exposed at /api/v1/metrics, rendered for human reading:

MetricWhat it tells you
HTTP requests / sec (5m avg)API load.
DB query duration (p95)Database health.
Worker queue depthBacklog signal.
Translation queue depthSame for translation.
Memory (RSS)Process memory usage.
Open file descriptorsLeak indicator if it grows over time.

For graphs and alerts, plug /api/v1/metrics into your Prometheus + Grafana stack.

If a check is failed with detail you can’t act on, capture:

  1. The full Diagnostics output (Export full report — JSON).
  2. The last 100 log lines around the failure (Logs → filter to relevant subsystem → Download).
  3. Your sanitised config dump.

Open a GitHub issue and attach all three. Maintainers can reproduce most issues from this combination alone.