3,915 stars · MIT, read from /blob/main/LICENSE on 2026-10-12, standard and unmodified · v1.6.0 (2026-08-31), settled by ungh's releases endpoint at 2026-08-31T15:56:47Z. A release-gap worth noting: v1.5.0 was 2025-12-15 and v1.4.0 2025-12-11, so about eight and a half months passed between releases while commits continued · Track this in Scout
One call that sends the same message to many messaging services at once, with the services registered up front.
▶Repo detailsthe review · specs · pros & cons · install
What it does
You create a service, such as a chat application, using its access token. You add the recipients for that service. You register it with the sender. Then you call send once, with a subject and a message, and every registered service receives it. Adding a second service is three more lines and no change to the sending code. The published list covers 33 services, of which 32 work and one, WhatsApp, is marked as unsupported. The project recommends creating your own sender object rather than using the shared global one, which matters in a program with more than one job. It has 1,245 commits since January 2021. The newest release is v1.6.0, from 31 August 2026, and code landed on 12 October 2026. What it does not promise is reliability. The README says it depends on outside services and client libraries, so it cannot guarantee delivery, and advises against relying on it where delivery is critical.
Why it matters
Who it suits. Anyone writing a small Go program that should report to a person rather than to a log file: a nightly job, a monitor, a scraper, a build step. It fits best where the choice of messaging service is not settled, because changing it later touches three lines instead of a rewrite. Skip it if you do not write Go, and skip it if the alert has to arrive, because the project says itself that it cannot promise that.
Verdict. A sensible small library, used correctly if alerts are a convenience and misused if they are a safety net. The warning in its own README is the honest centre of this entry: one library wrapping 33 services inherits 33 ways to fail quietly, and the project does not pretend otherwise. For anything where a missed message is a problem, send to a service whose delivery you can check. Two other notes. The release gap is wide — eight and a half months passed between v1.5.0 in December 2025 and v1.6.0 in August 2026 — while commits continued throughout, which is a project with a slow release habit rather than a quiet one. And WhatsApp is the single cross in the table, so do not plan around it. caronc/apprise at 17,200 stars is the answer for people who are not writing Go: it is a Python library and also a command-line program, under a BSD-2-Clause licence, so a shell script can use it. binwiederhier/ntfy at 33,500 stars takes the opposite approach, running one small service you own that pushes to your own phone, which removes the dependency on anybody else's messaging platform.
- One call reaches every registered service, so adding or swapping one does not touch the sending code.
- 33 services published in one table, with the one unsupported entry marked rather than hidden.
- MIT licensed, small, and with no services of its own to run.
- The project states it cannot guarantee delivery and advises against critical use.
- Go only, so it is no help in a Python or JavaScript program.
- Eight and a half months passed between the two most recent releases, so pinning a version may mean waiting for a fix.
caronc/appriseThe same idea as a Python library and a command-line program, at 17,200 stars, under a BSD-2-Clause licence; usable from a shell script.
Track this in Scout
binwiederhier/ntfyOne small service you run yourself that pushes messages to your own phone, at 33,500 stars, under Apache-2.0 and GPL-2.0 licences.
Track this in Scout
go get -u github.com/nikoksr/notify
