Uptime Kuma Notifications: Discord, Telegram, and Gotify Setup Guide

A monitor that goes down silently is worse than no monitor at all — it gives you false confidence. This handbook walks through connecting Uptime Kuma to three of the most popular notification channels: Discord, Telegram, and Gotify. Each section is self-contained, so you can jump straight to the service you want and follow it start to finish without reading the others.

Assumption: you already have Uptime Kuma installed and running, and can reach its web dashboard. If not, get that sorted first everything below happens inside Settings → Notifications.

Click here uptime kuma monitoring-tool setup guide

Choosing the Right Notification Method

All three services get an alert to you the moment a monitor changes state, but they solve slightly different problems.

	Discord	Telegram	Gotify
Best for	Teams already using Discord for chat/coordination	Personal mobile alerts, solo homelabbers	Fully self-hosted alerting, privacy-focused setups
Setup complexity	Low — no bot required, just a webhook URL	Low-medium — requires creating a bot via BotFather	Medium — requires running your own Gotify server first
Where alerts land	A Discord channel, visible to everyone with access	Your personal Telegram chat or a group	A dedicated Gotify app (web UI + mobile push app)
Third-party dependency	Discord (SaaS)	Telegram (SaaS)	None — 100% self-hosted if you self-host Gotify
Good fit if…	You want alerts visible to a team and discussable in-channel	You want push notifications on your phone with minimal setup	You don’t want any monitoring data touching a third-party service

A quick decision guide:

• Discord — if you or your team already live in Discord, this is the path of least resistance. Alerts show up as a bot message in whatever channel you choose, and multiple people can see and react to the same alert.
• Telegram — the fastest way to get a push notification directly to your phone with no infrastructure of your own. Good default for solo self-hosters.
• Gotify — the right choice if data sovereignty matters to you, or if you’re already running a self-hosted notification stack and don’t want to introduce a dependency on Discord’s or Telegram’s servers. Requires the most setup because you’re standing up your own server first.

None of these are mutually exclusive — Uptime Kuma lets you attach multiple notification channels to the same monitor, and many self-hosters run two channels in parallel (see Best Practices below).

Terminology check before we start: a webhook is just a URL that, when you send data to it, triggers an action somewhere else — in Discord’s case, posting a message into a channel. A bot token is a secret credential that lets an application (like Uptime Kuma) act as an automated account on a platform like Telegram. Treat both like passwords: anyone who has one can send messages as you.

Discord Setup

1. Prerequisites and Account Setup

You need:

• A Discord account
• A Discord server where you have permission to manage webhooks (if it’s your own server, you’re already set; if it’s a shared server, you’ll need the Manage Webhooks permission)
• A channel dedicated to alerts is strongly recommended — create one now if you don’t have it. In Discord, click the + next to your server’s channel list, choose Text Channel, and name it something like #uptime-alerts. Keeping alerts out of your general chat channels prevents them from getting buried or annoying people who don’t need to see them.

No bot creation or Discord Developer Portal work is required for this method — Discord’s webhook system handles the whole thing without you writing any code.

2. Credential Generation: Creating the Webhook URL

1. Open your Discord server and go to Server Settings.
2. Click Integrations in the left sidebar.
3. Click Webhooks, then New Webhook (or Create Webhook, depending on your Discord version).
4. Give the webhook a name — this is the name that will show as the message sender in Discord (e.g., “Uptime Kuma”).
5. Under Channel, select the alert channel you created in Step 1.
6. Click Copy Webhook URL. This URL looks like:

https://discord.com/api/webhooks/1234567890123456789/AbCdEfGhIjKlMnOpQrStUvWxYz1234567890abcdefghij

Save this somewhere temporarily (a password manager, not a plain text file left lying around) — you’ll paste it into Uptime Kuma in the next step. Anyone with this URL can post messages into your channel, so don’t share it or commit it to a public repo.

3. Uptime Kuma Configuration

1. In Uptime Kuma, click your profile icon (top right) → Settings.
2. Click Notifications in the left menu.
3. Click Setup Notification.
4. Under Notification Type, select Discord.
5. Fill in the fields:

Field	What to enter
Friendly Name	Any label for your own reference, e.g. “Discord — Ops Alerts”
Discord Webhook URL	The URL you copied in Step 2
Bot Display Name	The name shown as the message sender in Discord (can differ from what you set when creating the webhook)
Prefix Custom Message	Optional — text prepended to every alert, useful for @here or @role mentions to ping people on critical alerts

6. Toggle Default enabled ON if you want this notification applied automatically to every new monitor you create.
7. Toggle Apply on all existing monitors ON if you want it retroactively applied to monitors you’ve already set up.

4. Testing the Integration

Click the Test button before saving. A successful test sends an immediate message to your configured Discord channel — something like “Uptime Kuma Alert: Testing Successful.” If that message shows up, click Save and you’re done. If nothing arrives within a few seconds, don’t save yet — go to Troubleshooting below.

5. Troubleshooting Common Discord Issues

Problem	Cause	Fix
Test button shows an error immediately	Malformed or incomplete webhook URL	Re-copy the full URL from Discord — a truncated URL (missing part of the token) is the most common cause
Test succeeds but no message appears in Discord	Webhook is pointed at a different/wrong channel, or the channel is muted (message still exists, but you didn’t notice)	Check the channel dropdown in the webhook settings in Discord matches where you’re looking
“401 Unauthorized” or “404 Not Found” error	The webhook was deleted or regenerated in Discord after you copied the URL	Go back into Discord’s Integrations → Webhooks, generate a fresh URL, update it in Uptime Kuma
Messages arrive late or not at all during an outage	Discord rate-limiting (rare, but possible if you have many monitors alerting simultaneously)	Consolidate monitors into fewer, broader checks where possible, or spread notification channels across multiple webhooks
Formatting looks broken (raw markdown showing)	Not a common issue with Kuma’s default Discord formatting, but custom prefix text with unescaped special characters can occasionally look off	Keep prefix text simple; avoid unmatched *, _, or backtick characters

Telegram Setup

1. Prerequisites and Account Setup

You need:

• A Telegram account (mobile or desktop app)
• No pre-existing bot — you’ll create one in the next step through Telegram’s built-in bot manager, BotFather

Telegram bots have one quirk that trips up beginners: a bot cannot message you first. You have to send it at least one message before Uptime Kuma can post alerts to that chat. This is a spam-prevention measure built into Telegram, not a bug — just something to do in Step 2.

2. Credential Generation: Creating a Bot and Finding Your Chat ID

Create the bot:

1. Open Telegram and search for @BotFather (the official, verified bot-creation bot — check for the blue checkmark).
2. Start a chat and send: /newbot
3. BotFather will ask for a display name (what people see, e.g. “My Server Alerts”) and then a username (must be unique and end in bot, e.g. MyServerAlertsBot).
4. Once created, BotFather replies with a message containing your token: Use this token to access the HTTP API:123456789:ABCdefGhIJKlmNOPqrsTUVwxyz12345678
5. Copy and save this token — it’s the “Bot Token” you’ll paste into Uptime Kuma. Treat it as a secret; anyone with it can send messages as your bot.

Find your Chat ID:

1. Open a chat with your newly created bot (click the link BotFather gave you, or search for the bot’s username).
2. Send it any message — /start or just “hello” works fine.
3. You have two ways to get the Chat ID from here:
   • Easiest: go back to Uptime Kuma’s notification setup (next section) and use the Auto Get button next to the Chat ID field — it retrieves the ID automatically as long as you’ve already messaged the bot.
   • Manual: visit https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates in a browser (replace <YOUR_TOKEN> with your actual bot token). You’ll see a JSON response — find the "chat": { "id": ... } field. That number is your Chat ID.

3. Uptime Kuma Configuration

1. In Uptime Kuma: profile icon → Settings → Notifications → Setup Notification.
2. Under Notification Type, select Telegram.
3. Fill in the fields:

Field	What to enter
Friendly Name	Any label, e.g. “Telegram — Personal”
Bot Token	The token from BotFather
Chat ID	Click Auto Get, or paste the ID you found manually
Message Thread ID	Optional — only relevant if posting into a specific topic within a Telegram forum-style group

4. Optional toggles worth knowing:
   • Send Silently — delivers the message without triggering a phone notification sound/vibration (useful for low-priority monitors)
   • Protect Content — prevents the message from being forwarded or saved by recipients (relevant mainly for group chats)

4. Testing the Integration

Click Test. A successful test delivers a message from your bot directly into the Telegram chat you configured — you’ll see it appear in the app within a second or two. If it arrives, click Save.

5. Troubleshooting Common Telegram Issues

Problem	Cause	Fix
“Auto Get” returns nothing / empty Chat ID	You haven’t sent the bot a message yet, or Telegram hasn’t registered it	Send /start to the bot in the Telegram app, wait a few seconds, click Auto Get again
Test fails with “chat not found”	Wrong Chat ID, or the bot was never messaged in that specific chat	Re-check the ID against the getUpdates JSON response; make sure you’re looking at the right chat if you have multiple
Test fails with “Unauthorized” (401)	Bot token is incorrect or was regenerated	In BotFather, send /mybots, select your bot, then API Token → Revoke current token if needed, and update Uptime Kuma with the new one
Notifications arrive in the wrong chat	Chat ID belongs to a different conversation than expected (e.g., you tested in a group, then grabbed the ID from a DM)	Re-run the getUpdates check right after messaging the specific chat you want alerts sent to
Bot doesn’t respond to /start at all	Rare — sometimes a brand-new bot takes a minute to propagate on Telegram’s side	Wait 1–2 minutes and retry; if it persists, verify the bot wasn’t accidentally deleted via BotFather’s /deletebot

Gotify Setup

1. Prerequisites and Account Setup

Gotify is different from the other two: it’s a notification server you host yourself, so before touching Uptime Kuma you need a running Gotify instance. If you don’t have one yet, the quickest path is Docker:

docker run -d \
  --name gotify \
  -p 8080:80 \
  -v /opt/gotify/data:/app/data \
  gotify/server

Once running, log into the Gotify web UI (default http://your-server-ip:8080) with the admin credentials set during first launch. You’ll also want the Gotify mobile app (Android/iOS) or desktop client if you want push notifications outside the browser — install it and log in with the same server address and credentials.

2. Credential Generation: Creating an Application Token

Gotify organizes notifications by “Application” — each application gets its own token, so different tools (Uptime Kuma, other scripts, etc.) can be told apart in your notification feed.

1. In the Gotify web UI, click Apps in the sidebar.
2. Click Create Application.
3. Give it a name (e.g., “Uptime Kuma”) and an optional description.
4. Click Create. The new application appears in your list.
5. Click the eye icon next to the application to reveal its token — it looks like: AXcdEFghIJklMNo
6. Copy this token. This is what authenticates Uptime Kuma to post into this specific application’s notification stream.

3. Uptime Kuma Configuration

1. In Uptime Kuma: profile icon → Settings → Notifications → Setup Notification.
2. Under Notification Type, select Gotify.
3. Fill in the fields:

Field	What to enter
Friendly Name	Any label, e.g. “Gotify — Homelab”
Server URL	Your Gotify server’s address, e.g. http://gotify.yourdomain.com or http://192.168.1.50:8080
Application Token	The token copied in Step 2
Priority	Optional, 0–10. Higher priority messages are visually emphasized in the Gotify app; a common pattern is 5 for standard alerts and 8–10 for critical monitors

Note on ports: if your Gotify server runs on a non-default port (anything other than the standard HTTP/HTTPS ports), make sure the port is included in the Server URL field (e.g., http://192.168.1.50:8080, not just the IP). Leaving it off is one of the most common causes of connection failures with Gotify specifically, since Gotify has no default port convention the way some other services do. </blockquote>

4. Testing the Integration

Click Test. A successful test pushes a notification into the Gotify application you created — check the Gotify web UI’s Messages view, or your phone if you have the mobile app installed and are subscribed. If it shows up, click Save.

5. Troubleshooting Common Gotify Issues

Problem	Cause	Fix
Connection timeout / ETIMEDOUT error	Server URL missing the correct port, or a firewall blocking the connection between Uptime Kuma and Gotify	Confirm the full URL including port; if Kuma and Gotify are both in Docker, verify they’re on a shared network or that the host firewall allows the connection
“401 Unauthorized”	Wrong or revoked application token	Regenerate the token in Gotify (delete and recreate the application, or check if it was manually deleted), update Uptime Kuma
Test succeeds in Uptime Kuma but no push notification on phone	Mobile app isn’t subscribed to that specific application, or notifications are disabled at the OS level	Open the Gotify app, confirm the application appears and is enabled; check your phone’s OS-level notification permissions for the Gotify app
Messages appear in the web UI but never as a push	Gotify’s WebSocket connection from the mobile app has dropped (common after long idle periods or network changes)	Force-close and reopen the Gotify mobile app to re-establish the connection
Server URL works in a browser but not from Uptime Kuma	Uptime Kuma is running inside Docker and using localhost/127.0.0.1, which inside a container refers to the container itself, not the host	Use the Gotify container’s service name (if on the same Docker network) or the host’s LAN IP instead of localhost

Best Practices & Recommendations

When to use multiple notification channels together

Running two channels in parallel is a legitimate and common pattern — not redundancy for its own sake, but insurance against a single point of failure. If Discord has an outage, or your phone is on airplane mode, a second channel (say, Gotify running on your own infrastructure) still gets through. A reasonable default:

• Solo/homelab: Telegram (fast personal push) + Gotify (self-hosted backup, no third-party dependency)
• Small team: Discord (visible, discussable) + Telegram or email for after-hours personal alerts
• Anything customer-facing or business-critical: at least one self-hosted or non-SaaS-dependent channel (Gotify, or Uptime Kuma’s built-in email) so a third-party outage doesn’t blind you at the exact moment you need alerts most

Avoiding notification fatigue

The fastest way to make alerts useless is to get so many that you start ignoring them. A few concrete steps:

• Use Uptime Kuma’s Retries and Heartbeat Interval settings to avoid firing an alert on a single transient blip — require 2–3 consecutive failures before notifying, not one.
• Use the Resend Notification if Down X times setting sparingly — a repeat reminder every 10 failures is often more useful than every single check.
• Route non-critical monitors (a personal blog, a test environment) to a lower-priority channel, or a muted one, separate from anything customer-facing.
• In Gotify specifically, use the Priority field so your phone/desktop client can visually or audibly distinguish “this needs attention now” from “FYI.”

Security considerations

• Webhook URLs and bot tokens are credentials, not just configuration. Anyone with a Discord webhook URL can post into your channel; anyone with a Telegram bot token can message as your bot; anyone with a Gotify application token can push into your notification stream. Store them the way you’d store any other secret — not in a public repo, not in an unencrypted note.
• If a token or webhook is ever exposed (accidentally committed to Git, pasted somewhere public), regenerate it immediately rather than assuming no one found it — Discord webhooks and Gotify tokens can both be regenerated from the same place you created them.
• For Gotify specifically, since you’re running the server yourself, make sure it sits behind HTTPS (a reverse proxy with a real certificate) if it’s reachable outside your local network — sending your admin credentials and application tokens over plain HTTP on the open internet is avoidable risk for very little extra setup.
• Review your notification channel list periodically (Settings → Notifications in Uptime Kuma) and remove ones tied to services or bots you no longer use — an old, unmonitored webhook is a liability with zero upside.

Recommended alert thresholds by service

Service	Suggested use	Suggested retry/threshold
Discord	Team-visible alerts, non-urgent-but-important	2–3 retries before alerting; no need for silent/priority tuning
Telegram	Personal, time-sensitive alerts	1–2 retries; use Send Silently for low-priority monitors so it doesn’t wake you at 3 AM for something that self-recovers
Gotify	Self-hosted infrastructure alerts, especially anything Discord/Telegram depend on (e.g., your own reverse proxy or DNS)	Set Priority high (8–10) for anything that would also take down your other notification paths — this is your fallback channel, so treat it as the one that has to work

Once one of these is working, adding a second is largely repeating the same three steps (credential → configure → test) with a different provider the pattern is consistent across all 90+ notification types Uptime Kuma supports, not just the three covered here.