Echobell vs ntfy

Publish to a topic, or ring a specific person

ntfy is a clean pub/sub layer for notifications, open source and self-hostable. Echobell is narrower on purpose: private channels, three urgency levels including a real phone call, and Apple Watch delivery.

Echobell
VS
ntfy

Quick take

ntfy is the better tool if you want to own the server and treat notifications as a topic stream. Echobell is better if a specific person has to be woken up.

Choose Echobell when the alert must escalate to a ringing call, or when a guessable topic name is not an acceptable access model.

At a glance

Echobell

ntfy

Addressing model

Private channels with per-channel tokens and explicit subscribers

Public topic names anyone who knows them can subscribe to

Highest urgency

An incoming call with a ringtone and a call screen

Priority 5: louder sound and longer vibration

Apple Watch

Delivered to a paired Apple Watch

Notifications reach the watch through the phone as usual

Key differences

Both take an HTTP request and put it on your phone. They disagree about who a notification is addressed to and how far it can escalate.

Delivery model

Echobell

Different approach

A channel with its own trigger token, and subscribers you add

Two different models. ntfy's is simpler; Echobell's is closed by default.

ntfy

Different approach

A topic name — on the public server, knowing it is enough to subscribe

Urgency ceiling

Echobell

Built in

Calling mode rings with a full call screen

Echobell can escalate past the point where a notification stops working.

ntfy

Partial

Priority 5 is loud and vibrates longer, but stays a notification

Hosting

Echobell

Not available

Hosted service only

ntfy wins if you want the server, the data and the access rules to be yours.

ntfy

Built in

Open source, self-hostable, with auth and ACLs on your own instance

Message shaping

Echobell

Built in

Templates and conditions render and filter the payload server-side

Echobell keeps formatting out of every script that sends an alert.

ntfy

Partial

Email publishing and action buttons, but the sender still shapes the text

Where Echobell wins

Echobell trades ntfy's flexibility for reliability on the alerts that cannot be missed.

An alert that rings

Calling mode arrives as a phone call, through silent mode and Focus — the one thing priority levels cannot do.

Closed by default

A channel has a trigger token and a subscriber list, so nobody joins by guessing a name.

Formatting lives in one place

Templates and conditions run server-side, so ten different senders don't each need their own message-building code.

Best-fit scenarios

Teams tend to add Echobell next to ntfy for one of these reasons.

On-call has to actually wake up— When priority 5 has already been slept through once.
On-call has to actually wake up

When priority 5 has already been slept through once.

The topic name is doing security work— When an unguessable string is the only thing standing between an alert stream and a stranger.
The topic name is doing security work

When an unguessable string is the only thing standing between an alert stream and a stranger.

Alerts come from many senders— When each script formats its own message and they have all drifted apart.
Alerts come from many senders

When each script formats its own message and they have all drifted apart.

Moving from ntfy

Both take an HTTP POST, so a channel can shadow a topic while you compare.

  1. 1

    Create a channel per topic

    Keep the topic names as channel names so the mapping stays obvious.

  2. 2

    Point the publisher at the channel webhook

    Swap the ntfy topic URL for the Echobell webhook. JSON bodies carry across.

  3. 3

    Move priority 5 to Calling

    Anything you published with the highest priority is a candidate for a calling channel.

FAQ

Find answers to common questions about Echobell

No. ntfy's highest priority plays a longer, louder notification sound. Echobell's calling mode is an actual incoming call with a call screen.

Not inherently — ntfy's own guidance is to pick topic names that cannot be guessed, and a self-hosted instance can require authentication. It is a different access model, not a broken one.

No. ntfy is open source and yours to run; Echobell is a hosted service. If self-hosting is the requirement, ntfy is the right answer.

Keep the topics. Add a channel that rings.

Publish one high-priority topic to an Echobell calling channel and compare the next time it fires.