Cloud relays: Pushover vs Pushbullet vs Telegram bots vs Slack webhooks

Decision. For a docker-native homelab, Pushover is the default pick: a one-time $4.99 per platform [6], purpose-built notification apps, emergency alerts that retry until acknowledged [1], the strongest privacy posture [34], and 14 years under stable independent ownership [40]. Pick Telegram bots if you want $0 forever plus rich formatting and inline buttons, and don’t mind that bot traffic is never end-to-end encrypted [31]. Pick Slack incoming webhooks only if your lab already lives in Slack — ⚠ legacy webhooks are flagged for removal and the free plan caps history at 90 days [47][48]. Avoid Pushbullet as an alerting backend: a throttled free tier [9], the weakest privacy record [37], and the thinnest tooling support [18].

These are three categories, not four picks (read this first)

The biggest framing error is treating all four as interchangeable “send my phone a notification” services. They split into three delivery models:

• Personal push apps (Pushover, Pushbullet). Dedicated mobile/desktop apps that exist only to receive your notifications. Pushover is the pure case — a paid app whose sole job is displaying pushes [1]. Pushbullet is a cross-device sync tool (SMS mirroring, file transfer) that happens to expose a push API [2].
• Chat-bot relay (Telegram). Your alert lands as a message inside a normal Telegram conversation with a bot you created — not a dedicated notification app [4]. You read it in the same Telegram client you use for chatting.
• Team-chat webhook (Slack). Your alert posts into a Slack channel via a secret webhook URL [5]. Built for a team’s shared workspace, not a personal phone.

                          ┌─ Pushover ──► dedicated push app  (personal, paid)
  app / alert source ──►  ├─ Pushbullet ► sync app + push     (personal, freemium)
   (curl / Apprise /      ├─ Telegram ──► bot chat message    (chat client, free)
    Uptime Kuma / HA)     └─ Slack ─────► team channel post   (workspace, freemium)

This matters because it drives everything downstream: Pushover’s whole product is alert quality (priorities, retries, custom sounds); Telegram and Slack inherit the strengths and the privacy/retention model of a chat platform you don’t control.

At a glance

* Free tiers are constrained — see Pricing below.

Pricing & the real total cost

• Pushover — best value. A single $4.99 one-time purchase per platform (iPhone/iPad, Android, Desktop), no subscription [6]. Every account sends up to 10,000 messages/month free — and as of May 1 2026 that quota is pooled per account across all your apps rather than per-application [7]. A homelab realistically pays $5–10 total, once.
• Telegram — genuinely free. No per-message charges, no monthly API fee, no cap on the number of bots [10]. The only “cost” is the rate limit (below). This is the zero-budget winner.
• Slack — free works but squeezes. Incoming webhooks function on the Free plan but count against the 10-app integration cap, and messages older than 90 days become inaccessible behind the paywall [12][48]. Pro is ~€8.25/user/month (~€6.75/user/month annual) [11] — overkill for a notification sink.
• Pushbullet — the hidden-cost option. The free tier is throttled (sources cite ~100/month for message sending [9][42], and historically 500/month for API pushes [27]), pushing you to Pro at $4.99/mo or $39.99/yr [8] — i.e. it costs more per year than Pushover costs once.

Homelab / Docker integration

All four are first-class in the notification dispatch layer, but coverage thins out toward Pushbullet. Apprise ⭐ 16.7k [13] and shoutrrr ⭐ 1.6k [15] (the engine inside Watchtower) both support all four via one-line URL schemas [13][14].

• Uptime Kuma ⭐ 87.8k ships dedicated providers for all four among its 90+ channels [16].
• Home Assistant has first-class notify integrations for every one, including a rich Telegram-bot integration with send/edit/receive actions [17].
• Grafana alerting and n8n both expose Pushover, Telegram and Slack as native targets but have no Pushbullet option [18][20].

Raw curl from a container — ease ranks Pushover ≈ Slack > Telegram > Pushbullet:

# Pushover — one POST, two tokens
curl -s -F "token=$APP_TOKEN" -F "user=$USER_KEY" \
     -F "message=disk 90% on nas01" https://api.pushover.net/1/messages.json   # [1]

# Slack — one secret URL, JSON body
curl -s -X POST -H 'Content-type: application/json' \
     --data '{"text":"disk 90% on nas01"}' "$SLACK_WEBHOOK_URL"                # [5]

# Telegram — needs chat_id first (see ⚠ below)
curl -s "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
     -d chat_id="$CHAT_ID" -d text="disk 90% on nas01"                        # [21]

⚠ Telegram has a setup gotcha: a bot cannot message you until you message it first, then you scrape the numeric chat_id out of a getUpdates call before any sendMessage works [21]. Pushover (paste two tokens) and Slack (paste one URL) have no such dance.

Reliability, rate limits & message sizes

• Pushover’s emergency priority 2 is the standout for alerting: a notification repeats until you acknowledge it — retry ≥ 30 s, expire ≤ 10,800 s (3 h), capped at 50 retries, with an optional acknowledgement callback [1]. Nothing else here has it.
• Telegram is built for throughput — ~30 msg/s per bot globally (up to 1000/s with paid broadcasts) [23], but throttled to ~1 msg/s per chat and ~20/min per group, returning HTTP 429 with retry_after when breached [24].
• Slack webhooks are the tightest — roughly 1 request/second per channel, short bursts tolerated [26]. Fine for alerts, bad for a chatty firehose.

The resilience argument for using a cloud relay at all: a monitoring system cannot reliably watch itself [28], so the alert path should live on infrastructure separate from the thing it monitors. The dead-man’s-switch pattern routes an always-firing heartbeat through an external relay; when your local pipeline dies, the external service notices the silence and alerts you [29]. ⚠ The tradeoff is latency: self-hosters report third-party push can be noticeably delayed versus a local connection [30]. This is the strongest reason to keep a cloud relay in the mix even in an otherwise self-hosted lab — pair it with the self-hosted options (covered in the companion piece).

Privacy & security

Every option here means your alert content — hostnames, IPs, container names, stack traces — transits and is briefly stored on a third party’s servers. The degree differs sharply.

• Pushover — most privacy-forward. TLS for all transport; message content is stored in plaintext only long enough to deliver, then deleted once delivery is verified (undeliverable messages purged after 21 days) [34][35]. It also offers optional client-side end-to-end encryption (since app v5.0) that hides content even from Pushover’s own servers [34].
• Telegram — commonly misunderstood. Cloud Chats (private and group chats) use only server–client encryption and are explicitly not end-to-end encrypted; only Secret Chats add client–client E2E, and all bot traffic runs over Cloud Chats — so Telegram can read every bot alert [31]. Worse, a leaked bot token grants full control: anyone holding it can send as the bot and read chat data [32], and hardcoded-token leaks have already exposed real customer PII [33]. Treat the token like a password and revoke via BotFather if exposed.
• Slack — admin-visible and retained. Messages are stored server-side under admin-controlled retention policies [38]; workspace owners can export public/private channels and DMs to JSON [39]. On a workspace you don’t own, “deleted” alerts may persist in compliance records beyond your control.
• Pushbullet — weakest record. With sync enabled it uploads SMS data, contact lists, and contact images to its servers [36], and it has a documented history of Google Play privacy-disclosure friction over that data flow [37].

If alert payloads contain anything sensitive, Pushover (with E2E) is the only cloud relay here that can keep content opaque to the relay operator — otherwise self-host.

Service health & longevity (bus-factor)

• Pushover — the quiet standout. Run by Pushover, LLC (formerly named Superblock, LLC — the source of the misread “Superblock acquisition” rumor; it’s a rename, visible in the Android package net.superblock.pushover), a private, self-funded Chicago company operating continuously since March 2012 [40][41]. A 14-year track record of understated reliability.
• Telegram — healthiest by momentum. The Bot API shipped version 10.0 on May 8 2026, roughly 8 versions in 13 months (1–2 month cadence) [45] — free, actively developed, vast ecosystem.
• Slack — real deprecation risk for hobbyists. Legacy custom bots died March 31 2025; classic apps stop working November 16 2026 [46]; legacy incoming webhooks are explicitly flagged as “deprecated and possibly removed in the future,” steering you to recreate them inside a Slack app [47]. Plan for migration churn.
• Pushbullet — declining, not dead. It moved long-standing free features behind a $4.99/mo Pro tier and capped free messaging [42], and Manifest-V3 friction plus paywalling drove migration toward Microsoft Phone Link [44]. It is still maintained — updated June 2026, with MMS added in April 2026 [43] — but it has the weakest forward story of the four for alerting.

Bottom line

• Default homelab pick → Pushover: $4.99 once, dedicated apps, emergency retry-til-ack, best privacy, 14-year stability. The closest thing to “buy once, forget” in this space [6][1].
• Zero-budget power user → Telegram bot: free, rich formatting + inline buttons, huge ecosystem, very active API — accept that bot traffic is not E2E and guard the token [31][45].
• Already-in-Slack team lab → Slack webhook: trivial to wire up, but budget for deprecation migrations and the 90-day free-plan ceiling [47][48].
• Avoid for new alerting setups → Pushbullet: costs more per year than Pushover costs once, weakest privacy and tooling support, declining momentum [37][44].
• Architecture tip: put Apprise ⭐ 16.7k in front as your dispatch layer and target whichever relay you pick — then swapping relays later is a one-line URL change, not a rewrite [13]. And keep the relay on infrastructure separate from what it monitors [28].