Monitarr

A self-hosted micro-tool, honestly reviewed. No marketing fluff, just what you get when you run it.

TL;DR

• What it is: A minimal, no-frills web page that shows Sonarr/Radarr download queue status to people who don’t have access to the full *arr interfaces [1][README].
• Who it’s for: Self-hosters who run Sonarr/Radarr and want to let Overseerr/Jellyseerr users check their request progress — without handing out admin credentials [1][README].
• Cost: Free. GPL-3.0. No SaaS tier. No pricing page. [README]
• Key strength: Solves one very specific problem — “how do I show my friends where their downloads are?” — with minimal setup.
• Key weakness: No authentication. The author’s words, not mine: “It’s not pretty. It’s not secure. It’s not feature-rich. It’s not well-tested. It’s not well-anything.” [README] This is a personal project shared publicly, not a product.

---

What is Monitarr

Monitarr is a single-purpose web app that reads the download queue from Sonarr and/or Radarr via their APIs and displays the results as a simple webpage. That’s the entire feature set.

The origin story is spelled out plainly in the README: the author ran an Overseerr/Jellyseerr instance for friends and family. Those users would make requests, then have no way to see download progress without either bugging the admin or getting access to the Sonarr/Radarr dashboards — which exposes way more than you want to share [README][1]. Monitarr fills that gap. It’s a read-only status page, not a control panel.

The stack is Next.js (TypeScript) with Tailwind and shadcn/ui components, served from a Docker container or via yarn start. It connects to Sonarr and Radarr through their API keys, fetches the queue, and renders the results. There’s a refresh button that triggers a refresh job in the underlying apps and pulls fresh data [README]. As of this review: 99 GitHub stars, 3 forks, no formal releases published, one contributor.

To be clear about what this is not: Monitarr is not a media server manager, not an alternative to Sonarr/Radarr, and not a competitor to Overseerr. It lives alongside those tools as a thin read-only view into one specific piece of state — what’s currently downloading.

---

Why People Choose It

The use case is specific enough that there’s no real competition: you either build something like this yourself, use a spreadsheet to answer questions, or don’t care. Monitarr appeared on r/selfhosted [1] in late 2024, and the community response was immediate recognition of the problem it solves. The thread shows upvotes and engagement consistent with “yes, I have this exact problem” — not excitement about a new product, but relief that someone already built the thing.

The selfh.st weekly newsletter picked it up the same week, listing it in their “New Software” section alongside other community-released tools [3]. No formal press coverage, no comparison guides, because this isn’t the kind of tool that generates think pieces — it’s the kind of tool you deploy in 10 minutes and then forget exists.

What you’re buying (metaphorically, since it’s free) is: not having to explain to your friend for the fifth time that yes, Radarr has the movie, it’s queued, it’s downloading at 3 MB/s, no you cannot see that screen because it also has controls you shouldn’t touch.

---

Features

From the README and GitHub repository — no third-party feature counts exist:

Core:

• Download queue view for Sonarr (TV) and Radarr (movies) [README]
• Triggered refresh that calls the Sonarr/Radarr refresh job and re-fetches [README]
• Auto-refresh capability (added post-launch) [1]
• Download sorting (added post-launch) [1]
• BASE_PATH support for reverse proxy subfolder hosting (e.g., yourdomain.com/monitarr) [README]

Deployment:

• Docker image at ghcr.io/nickshanks347/monitarr:latest [README]
• Docker Compose config in the repository [README]
• Local build via yarn build && yarn start [README]
• Local dev server via yarn dev [README]

What it doesn’t have:

• Authentication of any kind. The author flags this explicitly: “This tool does not have any authentication (!) so make sure you run it in a secure environment.” [README]
• Role-based access, user accounts, or any permission model
• Download control (pause, cancel, prioritize)
• Historical data or charts
• Push notifications
• Mobile app or PWA
• Sonarr/Radarr instance switching from the UI (credentials are baked into environment variables)

The download speed display exists but the author notes directly: “The logic for the download speed is extremely inaccurate.” [README] Don’t use it to estimate completion times.

---

Pricing: SaaS vs Self-Hosted Math

There is no SaaS. There is no pricing. Monitarr is GPL-3.0, runs on your infrastructure, and costs nothing to license.

The only costs are:

• Compute: near-zero. The app idles between refreshes. It runs fine on the same machine as Sonarr/Radarr. No additional VPS needed if you’re already running the *arr stack.
• Your time: approximately 10–20 minutes if you follow the Docker Compose path and already have Sonarr/Radarr running.

There is no commercial alternative to compare against because no commercial product fills this exact niche. Sonarr and Radarr have their own web interfaces, but those are full control panels — not read-only status pages for non-admin users. Overseerr shows request status but not real-time download queue position. If you need the gap between those two things filled, your options are Monitarr, a custom script, or manually answering messages.

---

Deployment Reality Check

The install path is straightforward for anyone already running the *arr stack via Docker [README]:

services:
  monitarr:
    container_name: monitarr
    image: ghcr.io/nickshanks347/monitarr:latest
    ports:
      - 3000:3000
    environment:
      - SONARR_URL=http://sonarr:8989
      - SONARR_API_KEY=YOUR_SONARR_API_KEY
      - RADARR_URL=http://radarr:7878
      - RADARR_API_KEY=YOUR_RADARR_API_KEY
    restart: unless-stopped

If your *arr stack is on the same Docker network, http://sonarr:8989 resolves directly. If they’re on different hosts, use the actual IPs. The API keys come from Sonarr/Radarr’s Settings → General page.

What can go wrong:

The biggest risk is network exposure. Monitarr has zero authentication. If you expose it directly to the internet (even via a subdomain), anyone who finds the URL can see your entire download queue, including filenames. Filenames can reveal what content you’re downloading. This is a real concern depending on your jurisdiction and what you’re downloading [README]. The author’s recommendation to “run it in a secure environment” means: put it behind a VPN (Tailscale, WireGuard), or behind an authenticated reverse proxy (Authentik, Authelia), or only serve it on your local network.

There are no formal releases — the Docker image is tagged latest and pulled from the main branch. This is fine for a personal tool but means there’s no changelog or versioning to track [README]. Updates ship silently; breaking changes could arrive with a docker pull.

The project has 19 commits total. One contributor. No CI/CD badges in the README. This is not a maintained product with an SLA — it’s a tool that works until it doesn’t, and you own it when it breaks.

Realistic setup time for someone already running Docker and the *arr stack: 10–20 minutes. For someone setting up the *arr stack from scratch, see the broader ecosystem guides (the Medium *arr stack walkthrough [2] and the How-To Geek self-hosting overview [4] cover that ground well).

---

Pros and Cons

Pros

• Solves the exact right problem. If you run Sonarr/Radarr for multiple people, the “where’s my download?” question is real. Monitarr answers it without exposing admin controls [1][README].
• Minimal footprint. No database, no background workers, no scheduler. Reads from the *arr APIs on demand. Runs on the same box as everything else [README].
• Docker-first. Fits cleanly into existing *arr Docker Compose stacks [README].
• BASE_PATH support for reverse proxy setups where you want yourdomain.com/monitarr instead of a subdomain [README].
• Free, forever. GPL-3.0. No licensing costs, no usage limits, no future pricing changes [README].
• Honest about its limitations. A project where the README says “it’s not well-anything” is a project where you know exactly what you’re getting [README].

Cons

• No authentication. This is the only significant architectural concern, and it’s a real one. Putting this on a public URL without a proxy-level auth layer leaks your download queue to anyone [README].
• Download speed display is broken by the author’s own admission [README]. Don’t rely on it.
• No formal releases or versioning. Latest-only image, single contributor, 19 commits total [README]. Longevity is uncertain.
• No notifications. If a download fails or completes, Monitarr won’t tell anyone — users have to check manually or wait for auto-refresh [README].
• Read-only only. Users can see the queue but can’t interact with it in any way — can’t bump priority, can’t remove a stuck download [README].
• Sonarr/Radarr only. No support for Lidarr (music), Readarr (books), or other *arr apps. The name says “Sonarr/Radarr” and it means it [README].
• One-person project. Three forks, one watcher, no external contributors [README]. Assume you maintain it yourself if something breaks.

---

Who Should Use This / Who Shouldn’t

Use Monitarr if:

• You run Sonarr/Radarr and regularly field “is my show downloading?” questions from people who share your setup.
• You’re comfortable putting it behind a reverse proxy with authentication (Authelia, Authentik, Nginx basic auth) or behind a VPN.
• You want a zero-config read-only status page that integrates with your existing Docker Compose stack.
• You have no interest in building or maintaining something custom for this one-off need.

Skip Monitarr if:

• You’d expose it directly to the internet without an auth layer. The no-auth design is not a bug to be fixed later — it’s a stated characteristic of the project [README].
• You need users to interact with the queue (reprioritize, cancel, retry) — that’s Sonarr/Radarr’s own web interface, gated behind credentials.
• You need download completion notifications — look at Notifiarr or Apprise integrations with the *arr apps directly.
• You’re looking for a polished, maintained product with releases and an issue backlog. This is a personal tool [README].
• You need Lidarr or Readarr queue visibility — not supported.

---

Alternatives Worth Considering

There’s no direct competitor that fills exactly this slot, but depending on what you’re actually trying to accomplish:

• Sonarr/Radarr built-in web UI — the obvious baseline. Full control, full visibility, but requires giving users credentials with actual power.
• Overseerr / Jellyseerr — shows request status (approved, pending, available) but not real-time download queue position. Combine with Monitarr if you need both.
• Notifiarr — broader notification and integration platform for the *arr stack. Can push download status to Discord, Slack, etc. More setup, more features, overkill if you just need a web page.
• Tautulli — Plex-specific activity monitoring. Not relevant for Sonarr/Radarr queue status.
• Plex Meta Manager / Kometa — metadata management, not download monitoring.
• Build your own — Sonarr and Radarr both have well-documented APIs. A simple Next.js or plain HTML page reading GET /api/v3/queue is exactly what Monitarr is. If you need more than what Monitarr provides, building from the API is the path.

---

Bottom Line

Monitarr is a weekend project that does one thing: it takes your Sonarr/Radarr download queue and puts it on a webpage that doesn’t have admin controls attached. If you share your media server with non-technical family members or friends who use Overseerr to make requests, that’s a legitimate need with no polished solution in the *arr ecosystem. Monitarr fills the gap with minimal friction — Docker Compose, two API keys, done.

The caveats are real and worth repeating: no authentication, inaccurate speed display, one contributor, no releases. This is a tool you adopt knowing you own it. If the author stops maintaining it — which is plausible given the project size — you’re on your own. For what it is, it works. Don’t expect more than what the README describes, and you won’t be disappointed.

---

Sources

1. nicnic2001 (author), r/selfhosted — “monitarr - A simple Sonarr/Radarr download monitor” (Nov 2024). https://www.reddit.com/r/selfhosted/comments/1gst4rd/monitarr_a_simple_sonarrradarr_download_monitor/
2. Renato, Medium — “Weekend Project: Building a Self-Hosted Media Server with Plex, Sonarr, Radarr, and the *Arr Stack” (Nov 23, 2025). https://medium.com/@renatokauric/weekend-project-building-a-self-hosted-media-server-with-plex-sonarr-radarr-and-the-arr-stack-f07f57307cdc
3. Ethan Sholly, selfh.st — “This Week in Self-Hosted (22 November 2024)” (Nov 22, 2024). https://selfh.st/weekly/2024-11-22/
4. Ismar Hrnjicevic, How-To Geek — “These 5 apps proved to me that self-hosting was worth the effort” (Apr 16, 2026). https://www.howtogeek.com/im-new-to-self-hosting-these-are-the-apps-that-changed-everything-for-me/

Primary sources:

• GitHub repository and README: https://github.com/nickshanks347/monitarr (99 stars, GPL-3.0, 1 contributor)