The simplest way to send yourself a push notification

The task sounds trivial: "send a message to my own phone from a script." And yet developers routinely spend an afternoon on it, because the obvious tools were built for teams, marketing, or human-to-human chat — not for a single person poking their own device. Let's go through what people actually reach for, what each costs, and where the friction hides.

Emailing yourself

The zero-install classic. Your script sends an email; your phone shows a badge. It works, and if you already have SMTP creds lying around it's tempting. But email is a bad real-time channel. Delivery can lag minutes. Spam filters and rules can quietly bury the message. And critically, most phones don't buzz for a new email the way they buzz for a push — so the alert you wanted at 2am sits unread until morning.

Verdict: fine for a nightly digest, weak for "something is on fire right now."

A Slack (or Discord) incoming webhook

If your day already lives in Slack, this is a reasonable move. You create an incoming webhook, POST JSON to it, and a message lands in a channel. The wiring is genuinely one request:

curl -X POST "https://hooks.slack.com/services/T00/B00/xxxx" \
  -d '{"text":"New sale: $49"}'

The hidden cost is reaching your lock screen. A Slack message is a chat notification, subject to your channel mute settings, Do Not Disturb schedule, and per-channel overrides. Getting a single automated ping to reliably buzz your phone — and not drown in the same channel's chatter — takes tuning. You're also routing a personal alert through a third-party workspace you may not control.

A Telegram bot

Telegram bots are a developer favourite for good reason: the Bot API is clean, delivery is fast, and it's free. The catch is the one-time setup. You talk to @BotFather, get a token, then discover you also need your personal chat_id, which you obtain by messaging the bot and reading an getUpdates response. It's ten minutes of yak-shaving you do once and then forget how you did.

Telegram is a great answer if you're already a Telegram user. If you're not, installing a whole messaging app to notify yourself is the tail wagging the dog.

Self-hosted ntfy

ntfy is the open-source darling of this space, and deservedly so. Pub-sub over HTTP, dead-simple curl publishing, native apps, and you can self-host the whole thing. If you care about owning your data end to end, this is the principled choice. We even wrote a whole Lert vs ntfy comparison because we respect it that much.

The cost is operational. Self-hosting means a VPS, a domain, TLS certificates, and being the person who gets paged when the notification server itself goes down. Plenty of people run hosted ntfy to avoid exactly that — at which point you're back to "a hosted service with a URL," just a different one. We dig into this tradeoff in self-hosted vs hosted push notifications.

Pushover

Pushover is the veteran commercial answer, and it's good: reliable delivery, a one-time app purchase, priority levels, and a simple API. The friction is modest but real — you register an application to get an API token, use your user key, and send both with each request. Two identifiers instead of one, plus an app-registration step. For many people that's totally acceptable; it's just not nothing.

Twilio SMS

SMS has one superpower: it reaches a phone with no app installed and no data connection. If you need to alert someone who isn't you, or reach a device in a dead zone, Twilio (or similar) earns its place. But for notifying your own smartphone, SMS is expensive per message, adds a phone-number and account-setup burden, and gives you a plain text string with no title, no styling, no priority. Overkill for a personal build alert.

The pattern worth wanting

Step back and look at what all the friction has in common. It's not the sending — every option above is roughly "POST some text." The friction is identity: an API token here, a bot token and chat_id there, a user key and app token, a workspace, a server. Each is a small tax, and they add up to the difference between "I'll wire that up now" and "I'll do it later" (which means never).

So the design worth wanting collapses identity into the destination itself. Your phone hands you one opaque URL. That URL is the credential — possessing it is the authorization to notify that phone, and nothing else. No account to create, no key to manage separately, no SDK to install. Send:

curl -X POST "https://lert.dev/p/your-id" \
  -H "Content-Type: application/json" \
  -d '{"title":"Backup done","body":"14.2 GB in 3m"}'

That's the whole integration. It works identically from Python, a shell, a cron job, a CI pipeline, or an AI agent. This is the model Lert is built on, and it's why the URL-as-authentication idea is worth understanding in its own right — including its honest tradeoffs, like treating that URL as a secret you can rotate.

So which should you use?

• Already glued to Slack or Telegram? Use their webhook/bot. The tool you already have beats a new one.
• Data sovereignty is a hard requirement? Self-host ntfy and own the stack.
• You want a real iOS push with zero setup and don't want to run anything? A single-endpoint hosted service like Lert is the shortest path — download, copy URL, POST.
• Need to reach a non-smartphone or someone who isn't you? SMS via Twilio.

There's no universally correct answer — only the one that adds the least friction to your situation. But if the situation is "I, a developer, want my own phone to buzz when my code says so," the honest recommendation is the one-request model. It removes the only hard part.