Shoutrrr

Last reviewed Sep 13, 2026 · 772 words

You are probably already running Shoutrrr. It is the notification library inside Watchtower, so anyone who has set WATCHTOWER_NOTIFICATION_URL has used its one real idea: a notification target expressed as a single URL, such as discord://token@channelid or ntfy://ntfy.sh/homelab, so that every tool sharing the library gets every supported service for free. The standalone CLI is a single Go binary of a few megabytes with no daemon, no config file and no database, which makes it the right shape for cron jobs and backup scripts and the wrong shape for anything that needs a server.

One URL per destination is the entire interface

Each service gets a scheme. A Discord webhook becomes discord://webhooktoken@webhookid. A Gotify server becomes gotify://gotify.example.com/apptoken. A ntfy topic becomes ntfy://ntfy.example.com/topic. Telegram, Slack, Matrix, Pushover, email over SMTP, generic webhooks and a couple of dozen others follow the same pattern, documented per service at containrrr.dev/shoutrrr. The URL is the whole configuration, which means the whole configuration fits in one environment variable and one line of a script:

shoutrrr send \
  --url "ntfy://ntfy.example.com/backups" \
  --message "restic backup finished on $(hostname) at $(date +%H:%M)"

Two subcommands earn their keep: shoutrrr verify --url ... parses a URL and prints what it understood, which catches the escaped-character mistakes that make webhook tokens fail silently, and shoutrrr generate <service> walks you through building a URL interactively.

Where it sits in a self-hosted stack

Shoutrrr is glue, and it belongs at the end of pipelines that already exist. The three places I put it: after a backup command in the same cron line, so a failed exit status sends a different message than success; in Watchtower, where the library is embedded and you only supply the URL; and inside small Go tools of my own, where importing the library costs almost nothing and saves writing a Discord client. It has no queue, no retry beyond what the transport does, and no fan-out to multiple recipients except by listing multiple URLs. If a message must not be lost, the reliability lives in your script, not in Shoutrrr.

Apprise has more targets and an HTTP server

The honest comparison is Apprise, the Python equivalent, which supports far more services and, in its API flavour, runs as a small web service that other tools can POST to. That server is the deciding difference. If you want one notification endpoint that a dozen apps on your network can hit over HTTP, Apprise's API container is the right tool and Shoutrrr cannot do it. If you want a dependency-free binary you can drop into a container image or a Pi and call from shell, Shoutrrr's 32 MB footprint and single-file install win. The catalogue's "fewer targets" con is accurate; check the service list before committing, especially for the less common push apps.

Check the repository's pulse before depending on it

Development at the containrrr organisation slowed sharply after 2023, for both Shoutrrr and Watchtower, and community forks have carried on releases. That is not a reason to avoid it; the URL format is stable and the existing services keep working. It is a reason to pin a version, check the last commit date on whatever repository you install from, and prefer the fork that your Watchtower build actually uses so the two stay in step. The container updates guide covers the Watchtower side of that.

What it is not

It is not a notification server, so it will not store history, show you a feed, or deliver to your phone by itself; that job is Gotify's or ntfy's, and Shoutrrr is how you reach them. It is not a monitoring tool; Uptime Kuma has its own notification layer, as do most tools in the automation category. And it is not a scheduler. It sends one message when invoked, then exits, and everything else is your problem.

What I'd do

Run ntfy or Gotify as the actual notification server, then use Shoutrrr as the sender everywhere a shell script needs to reach it: backup jobs, certificate renewals, disk-space checks. Install the pinned binary once per host, keep the URLs in a root-only environment file, and test each with shoutrrr verify before trusting it. If I later needed apps to send notifications over HTTP without installing anything, I would add Apprise's API container alongside rather than replacing Shoutrrr in the scripts that already work.