Monitoring and Health Checks for a Plex and Arr Homelab

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

A media automation stack can look healthy while quietly failing. Downloads may be stuck. Imports may be blocked by permissions. Tdarr may be filling a cache disk. Plex may be transcoding because clients are not direct playing. A NAS mount may have disappeared. Monitoring is how you catch those problems before they become a weekend rebuild.

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.

1. 1. StorageMounts + Free Space

   Verify NAS mounts, marker files, local cache space, and download volumes before queues grow.

2. 2. QueuesArr + SAB Activity

   Look for stuck imports, failed downloads, wrong categories, and old queue items.

3. 3. TdarrReview / Error Items

   Review failed, cancelled, risky HDR, or unexpected transcode jobs instead of letting them disappear.

4. 4. PlexPlayback + Metadata

   Confirm playback, scans, library visibility, and refresh behavior after file changes.

5. 5. SecurityProxy + API Logs

   Check suspicious requests, certificate health, auth failures, and API-key errors.

6. 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

Sonarr, Radarr, and Prowlarr have health surfaces. Use them. A warning about an unavailable indexer, invalid root folder, failed download client, or permissions issue is not cosmetic. These warnings usually point directly at the next outage.

Queue Cleanup

A stuck queue creates confusion. Before bulk searching or enabling a new list, clean failed jobs and understand why they failed. If a job is missing articles, failed unpack, wrong category, or import-blocked, the fix is different. Deleting everything blindly makes the symptoms disappear but not the cause.

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

• Automate mount marker checks.
• 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 missing marker file.
• 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

#!/usr/bin/env bash
set -euo pipefail
echo "== Host =="
hostname
uptime
df -h /data /data/downloads /data/cache 2>/dev/null || true

echo "== Mounts =="
findmnt /data/media || echo "media mount missing"
if test -f /data/media/.media_mount_marker; then
  echo "media marker ok"
else
  echo "media marker missing"
fi

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

nvidia-smi --query-gpu="$gpu_fields" --format=csv \
  2>/dev/null || echo "nvidia-smi failed"

echo "== Containers =="
docker ps --format 'table {{.Names}}\t{{.Status}}' 2>/dev/null || true

Application API Checks

For deeper monitoring, use each app API with a read-only mindset. Keep API keys in a root-readable environment file and never paste them into public posts. Track queue counts, health warnings, failed downloads, and Tdarr error states.

curl -fsS "http://127.0.0.1:7878/api/v3/health?apikey=YOUR_RADARR_API_KEY" | jq .
curl -fsS "http://127.0.0.1:8989/api/v3/health?apikey=YOUR_SONARR_API_KEY" | jq .
curl -fsS "http://127.0.0.1:9696/api/v1/health?apikey=YOUR_PROWLARR_API_KEY" | jq .

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 filesystem and marker. Confirm services do not write into the bare mount point.
• Capacity warning: Lower a test threshold above 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 filesystem and marker 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.

• Plex Homelab Architecture: Storage, GPU Transcoding, and Library Design
• Media Server Storage Design: NAS, CIFS/NFS Mounts, Permissions, and Local Cache
• Prowlarr Setup Guide: Clean Indexer Management for Sonarr and Radarr
• Sonarr Homelab Setup Guide: Install, Update, Optimize, and Connect to Tdarr
• Radarr Homelab Setup Guide: Install, Update, Optimize, Lists, and Tdarr Integration
• SABnzbd Performance Tuning for a Homelab Media Server
• Custom Formats and Quality Profiles Explained for Radarr and Sonarr
• Radarr Import Lists That Do Not Fill Your Library With Junk
• Plex + Tdarr GPU Strategy: Sharing NVIDIA GPUs Without Hurting Playback
• Reverse Proxy for Media Apps: Nginx Proxy Manager, SSL, Access Lists, and Security
• Backup and Disaster Recovery for Plex, Sonarr, Radarr, Tdarr, Prowlarr, and SABnzbd
• Monitoring and Health Checks for a Plex and Arr Homelab
• The Complete Plex, Arr, and Tdarr Homelab Media Automation Series

Related foundation: Building a Production-Grade Tdarr GPU Transcoding Stack for a Homelab.

References

• Radarr System and Health
• Sonarr System and Health
• Plex Scheduled Tasks
• SABnzbd Configuration Overview
• Tdarr Installation and Service Documentation
• Google SRE: Monitoring Distributed Systems