Monitoring and Health Checks for a Plex and Arr Homelab

06/21/2026 10/02/2026

Tech Guru

Monitor the outcomes that keep a media stack useful: mounted storage, free space, successful imports, playable files, healthy queues, available transcode resources, current certificates, and restorable backups. Start with one daily report and a few actionable alerts before building a large dashboard.

Rights and lawful use: Monitor only systems and media workflows you administer, and use the stack only with media you own or are authorized to process. Health checks do not create permission to acquire, retain, share, or transcode copyrighted material.

Who this is for: New operators can follow the daily checks without building a full observability platform; experienced administrators can use the evidence and threshold sections to design alerts around the actual failure modes of Plex, Arr applications, SABnzbd, Tdarr, storage, and GPUs.

Why Monitoring Matters

Check for stuck downloads, permission-blocked imports, growing Tdarr cache, unexpected Plex transcoding and missing NAS mounts even when the web interfaces load. Each signal needs an owner and a next diagnostic step; a dashboard alone cannot prevent an outage or prove recovery.

What to Monitor

Plex playback and transcode activity.
Sonarr and Radarr health warnings.
Prowlarr indexer failures and rate limits.
SABnzbd queue, speed, failed jobs, and API warnings.
Tdarr queue, failed jobs, review-required files, and node status.
GPU driver health and active encode sessions.
Disk capacity for media, downloads, and cache.
NAS mount availability.
Backup freshness.
Reverse proxy access and certificate renewal.

Interactive health loop

Daily Media Stack Health Loop

A green web UI is not enough. Check the signals that prove the workflow is actually healthy.

1. StorageMounts + Free Space
Verify NAS mounts, marker files, local cache space, and download volumes before queues grow.
2. QueuesArr + SAB Activity
Look for stuck imports, failed downloads, wrong categories, and old queue items.
3. TdarrReview / Error Items
Review failed, cancelled, risky HDR, or unexpected transcode jobs instead of letting them disappear.
4. PlexPlayback + Metadata
Confirm playback, scans, library visibility, and refresh behavior after file changes.
5. SecurityProxy + API Logs
Check suspicious requests, certificate health, auth failures, and API-key errors.
6. RecoveryBackup Freshness
Confirm recent config backups and verify reports are redacted before sharing.

Redacted reportsHealth checks should log status and counts, not raw API keys or tokens.

Outcome healthHealthy means imports complete, Plex sees files, backups exist, and queues drain.

Daily Human Review

Not every check needs a full dashboard. A daily report can be enough. The report should tell you what changed, what failed, what is stuck, and what needs human review. Tdarr especially benefits from this because failed or risky transcodes can otherwise disappear into a queue.

Daily review sections:
  Plex: active transcodes, library scan errors
  Radarr: queue errors, missing imports, health warnings
  Sonarr: queue errors, missing imports, health warnings
  Prowlarr: failed indexers, rate limits
  SABnzbd: failed jobs, API warnings, disk space
  Tdarr: failed, cancelled, review-required jobs
  Host: mounts, disk, GPU, backups

Storage Alerts

Disk alerts should separate final media, downloads, and cache. A full Tdarr cache should not be confused with a full movie library. A full incomplete download disk should not take down Plex. Set thresholds for each path and alert before the disk is critical.

Mount Checks

NAS mounts deserve explicit checks. A directory existing is not enough. An empty mount point can look like a folder. A better check confirms that the filesystem type is mounted, a known marker file exists, and the media services did not start against an empty directory.

GPU Checks

gpu_fields="name,driver_version,utilization.gpu"
gpu_fields="$gpu_fields,memory.used,memory.total"

nvidia-smi --query-gpu="$gpu_fields" --format=csv

nvidia-smi pmon -c 1

GPU checks should confirm the driver is loaded, the expected GPU is visible, and active processes match what you expect. During a Plex transcode, Plex should appear. During a Tdarr GPU encode, the Tdarr/FFmpeg process should appear. After a kernel update, this check becomes mandatory.

Application Health Pages

Review Sonarr, Radarr and Prowlarr health warnings for unavailable indexers, invalid root folders, failed download clients and permissions. Record the affected integration and follow its diagnostic path. A warning is a reason to investigate, not a prediction of the next outage.

Queue Cleanup

Before bulk searches or a new list, preserve the failed job state and relevant logs, then distinguish missing articles, unpack failure, wrong category and blocked import. Correct the cause and retry or remove only the reviewed jobs. Clearing a queue before recording that evidence can hide the failure without fixing it.

Backup Monitoring

Backups need monitoring too. Check the timestamp of the newest backup for each app. Check size so a broken backup job does not produce an empty file. Keep enough versions to roll back after a bad configuration change.

Beginner Checklist

Look at Sonarr and Radarr health once per day until stable.
Check SAB failed downloads and warnings.
Check Tdarr failed and review queues.
Check free space on download, cache, and media paths.
Confirm Plex users are not buffering during Tdarr work.
Confirm backups ran.

Technical Checklist

Check the expected mounted source and filesystem type; a marker alone is insufficient.
Automate disk threshold alerts.
Automate Tdarr review reports.
Track GPU driver status after updates.
Track queue age, not just queue count.
Alert on backup age and size.
Log reverse proxy 4xx/5xx spikes.
Document manual remediation steps.

How Monitoring Closes the Series

Monitoring is the final operational layer. Architecture, storage, app configuration, custom formats, GPU strategy, reverse proxying, and backups all matter. Monitoring tells you whether those decisions are still working next week after updates, new imports, new lists, and new users.

Beginner Walk-Through: Green Does Not Always Mean Healthy

An app can have no visible red error and still be behind, stuck, or stale. Plex may be working but scanning constantly. Radarr may be healthy but full of failed imports. SAB may be downloading fast but leaving failed jobs. Tdarr may be processing but accumulating risky files. Monitoring should look at outcomes, not just whether the web UI loads.

Technical Alert Thresholds

Download cache over 80 percent full.
Tdarr cache over 80 percent full.
Media mount absent or not the expected source and filesystem type.
No successful backup in more than 24 hours.
Any failed Tdarr job older than one day.
Any Sonarr/Radarr import blocked longer than one hour.
GPU not visible after reboot.
Certificate expiring within 14 days.

These are starting examples, not measured universal limits. A backup job that runs weekly should not alert at 24 hours, and a cache that grows quickly may need earlier warning than 80 percent. Set each threshold from filesystem size, normal growth, job schedule, recovery time, and the time available for a human response. Record why the threshold exists and revise it after a real alert.

Daily Review Philosophy

The goal is not to create noisy alerts for everything. The goal is to surface the few things that need a decision. Failed transcodes, missing mounts, failed backups, and stuck imports deserve attention. Normal queue movement does not.

Implementation Playbook: Daily Health Script

Ubuntu Daily Checks

For a NAS-backed /data/media, set the expected source and filesystem type from the approved storage inventory. Set CHECK_NVIDIA=1 only when this host should have an NVIDIA device. The script returns a failure status when an inspection command or mount comparison fails. It does not enforce free-space thresholds, compare an expected container list, test application workflows or send notifications; connect those separate checks to a tested scheduler and alert route. A point-in-time mount result is not a runtime interlock.

#!/usr/bin/env bash
set -u
status=0
: "${EXPECTED_MEDIA_SOURCE:?set the approved NAS share/export}"
: "${EXPECTED_MEDIA_FSTYPE:?set the approved filesystem type}"
printf '== Host ==\n'
hostname || status=1
uptime || status=1
df -h /data /data/downloads /data/cache || status=1
printf '== Mount ==\n'
actual_source=$(findmnt -n -r --mountpoint /data/media -o SOURCE) || status=1
actual_type=$(findmnt -n -r --mountpoint /data/media -o FSTYPE) || status=1
if [[ "$actual_source" != "$EXPECTED_MEDIA_SOURCE" || "$actual_type" != "$EXPECTED_MEDIA_FSTYPE" ]]; then
  printf 'Expected media mount not verified\n' >&2
  status=1
fi
printf '== GPU ==\n'
case "${CHECK_NVIDIA:-0}" in
  1) nvidia-smi --query-gpu=name,driver_version,utilization.gpu,memory.used,memory.total --format=csv || status=1 ;;
  0) printf 'NVIDIA check disabled for this report\n' ;;
  *) printf 'CHECK_NVIDIA must be 0 or 1\n' >&2; status=1 ;;
esac
printf '== Containers ==\n'
docker ps --format 'table {{.Names}}\t{{.Status}}' || status=1
exit "$status"

Application API Checks

Prepare three reviewed curl configuration files under an administrator-controlled ~/.config/media-health directory, owned by the monitoring account with mode 0600. Each file needs its local health URL and an X-Api-Key header containing that app's protected key. Use http://127.0.0.1:7878/api/v3/health for Radarr, port 8989 with the same path for Sonarr, and http://127.0.0.1:9696/api/v1/health for Prowlarr, adjusting reviewed URL-base settings as needed. Do not put the key in the URL, shell arguments or reports. The command below uses the file without printing its contents and fails on request, parsing or nonempty-health-array results. An empty array still does not prove import, playback or backup health. Treat each API credential as privileged, not as a read-only key merely because this check uses GET.

(
set -euo pipefail
# Pre-create these reviewed files privately; never place keys in URLs.
for app in radarr sonarr prowlarr; do
  config="$HOME/.config/media-health/$app.curl"
  [[ -f "$config" && ! -L "$config" && -O "$config" ]]
  [[ "$(stat -c %a "$config")" == 600 ]]
  printf '%s health clear: ' "$app"
  curl --disable --config "$config" --fail --silent --show-error --max-time 10     | jq -e 'type == "array" and length == 0'
done
)

Docker Health View

docker compose ps
docker stats --no-stream
docker logs --tail=100 radarr
docker logs --tail=100 sonarr
docker logs --tail=100 sabnzbd
docker logs --tail=100 tdarr

Alert Priorities

Critical: media mount missing, cache disk full, GPU missing after reboot, backups not running.
High: Radarr/Sonarr imports blocked, SAB failed jobs accumulating, Tdarr failures older than one day.
Medium: indexer failures, certificate expiration warnings, queue age increasing.
Low: routine download backlog during normal activity.

Validation and Evidence

This revision is documentation-backed. TechGeeks did not run the sample script, call the application APIs, trigger alerts, measure queue baselines, or restore a media-stack backup for this article. The commands are starting points that must be reviewed for local paths, versions, permissions, and secret handling.

Mount failure: On a nonproduction path or maintenance window, remove access to a test mount and confirm the check detects the missing or unexpected filesystem. Confirm services do not write into the bare mount point.
Capacity warning: Set a test utilization threshold below current utilization and confirm one notification arrives with the correct filesystem, value, time, and runbook link.
Application failure: Stop one noncritical test container and verify both black-box reachability and the application's own health or queue signal.
Stuck-work signal: Use a disposable queue item or a safely adjusted test threshold. Confirm the alert identifies age and state without deleting or changing the item.
Secret handling: Confirm API keys are not printed to reports, process arguments retained by monitoring, shell history, web dashboards, or public logs.
Recovery: Restore one application configuration and representative database to an isolated host, then verify login, paths, queue state, permissions, and expected records.

For each alert, save the trigger, observed value, notification time, acknowledgement time, corrective action, and clear condition. This proves that the alert path works in that test. It does not prove every failure will trigger or that the chosen threshold is correct.

Rollback and Failure Handling

Monitoring changes can create their own outage through aggressive remediation, excessive API calls, leaked credentials, or a script that exits unexpectedly. Deploy checks read-only first. Keep the previous timer, cron entry, alert configuration, and secret file until the new report completes several normal cycles.

If an alert floods, disable its notification route without deleting the underlying metric or event history.
If a script affects load, stop its timer and restore the prior interval before tuning queries.
If an API key appears in logs, revoke it, issue a replacement with the narrowest supported access, remove exposed copies, and review access history.
If a mount disappears, stop writers before remounting; verify the expected filesystem source, type and service access before starting media services.
If a GPU disappears after an update, pause Tdarr processing and return playback to CPU or direct-play operation rather than repeatedly restarting active work.

What This Evidence Does Not Prove

An HTTP 200 response or green container state does not prove imports, playback, transcoding, storage, or backups work.
A recent backup timestamp and nonzero file size do not prove the backup can be restored.
A visible GPU and active process do not prove hardware transcoding is correct, efficient, or producing acceptable output.
A quiet queue does not prove automation is healthy; searches, feeds, or download clients may have stopped producing work.
The sample thresholds do not prove service-level objectives or fit every library, disk, job cadence, or household response time.

Security, Privacy, Legal, and Recovery Boundaries

Security: Treat application APIs, Docker access, monitoring dashboards, and notification webhooks as privileged. Keep keys out of URLs where supported, restrict files, and do not give a health script write access it does not need.
Privacy: Logs and dashboards can reveal titles, user activity, IP addresses, hostnames, paths, and account identifiers. Minimize collection, restrict viewers, and set retention.
Legal: Monitor and automate only media and services you own or are authorized to use. The preserved lawful-use boundary applies to downloads, storage, sharing, and transcoding.
Recovery: Keep monitoring configuration and runbooks off the monitored host, protect backup credentials separately, and test an isolated application restore. Monitoring is evidence about recovery state, not the recovery copy itself.

Related TechGeeks

This monitoring chapter is the operational checkpoint for the media automation series: use the linked component guides to correct a failing service, then return here to confirm the complete request, download, import, transcode, and playback path recovers.

References

Categories: Homelab, Linux and Homelab, Plex, and Tutorials

Tags: Automation Health Checks Homelab Monitoring Plex Radarr Sonarr Tdarr