How to Monitor Your API Uptime with Telegram Alerts

Your API goes down at 2 AM. Your users start hitting errors. Some of them tweet about it. You find out the next morning when you check Slack and see a thread full of complaints. By then the damage is done — frustrated users, lost transactions, and a reputation hit that takes days to recover from.

The fix is simple: monitor your endpoints and get a Telegram message the moment something stops responding. Your phone buzzes, you SSH in, and you fix it before most users even notice. Here's how to set that up, from a DIY script to a managed solution.

Option 1: A Custom Monitoring Script (The DIY Way)

The simplest approach is a script that pings your API on a schedule and alerts you when it gets a non-200 response or times out. Here's a Python version using the Telegram Bot API directly:

import time
import requests

API_URL = "https://api.yourapp.com/health"
CHECK_INTERVAL = 60  # seconds
TELEGRAM_TOKEN = "123456:ABC-DEF..."
TELEGRAM_CHAT_ID = "987654321"

def send_telegram(message):
    requests.post(
        f"https://api.telegram.org/bot{TELEGRAM_TOKEN}/sendMessage",
        json={"chat_id": TELEGRAM_CHAT_ID, "text": message},
    )

was_down = False

while True:
    try:
        r = requests.get(API_URL, timeout=10)
        if r.status_code != 200:
            if not was_down:
                send_telegram(f"API is DOWN — status {r.status_code}")
                was_down = True
        else:
            if was_down:
                send_telegram("API is back UP")
                was_down = False
    except requests.RequestException:
        if not was_down:
            send_telegram("API is DOWN — connection failed")
            was_down = True

    time.sleep(CHECK_INTERVAL)

This works for a single endpoint. But once you need to monitor more than one URL, the problems stack up:

• You need to host the monitor. The script needs to run somewhere 24/7. If it's on the same server as your API, it goes down when your API goes down.
• Telegram Bot API boilerplate. You need to create a bot, get the token, find your chat ID, and handle the HTTP calls yourself.
• No recovery alerts. The script above handles it, but many quick implementations forget to alert when the service comes back up — so you don't know if the fix worked.
• One platform only. If your team uses Discord or Slack, you need separate code for each platform's API.
• No history. There's no record of when outages happened, how long they lasted, or how often they occur.

For monitoring one personal project, a cron script is fine. For production services where downtime costs money, you need something more reliable.

Option 2: Built-In Health Checks (The Managed Way)

NotificationsBot has a built-in health check feature. You add a URL in the dashboard, and the service polls it every 60 seconds from an external server. When the status changes — up to down, or down to up — it sends an alert to everyone subscribed to that channel, on whatever platform they use.

No scripts to write, no bots to create, no servers to maintain for the monitor itself. You just add the URL and choose who gets alerted.

Setting Up Uptime Monitoring with NotificationsBot

• Sign up at app.notificationsbot.com — free tier, no credit card
• Create a channel (e.g., uptime-alerts)
• Add a subscriber — choose Telegram, Discord, or Slack
• Link the subscriber — connect their account through the onboarding flow
• Assign the subscriber to the channel
• Add a health check — enter the URL you want to monitor and assign it to the channel

That's it. The service starts polling immediately. When your API goes down, your phone buzzes. When it comes back up, you get a second message confirming it's recovered.

What to Monitor

Not every endpoint needs uptime monitoring. Focus on the ones where downtime has real impact:

• Health check endpoint — a dedicated /health or /api/status route that returns 200 when your service is running. This is the most common and most useful.
• Landing page / marketing site — if your website is down, potential customers can't find you.
• API gateway or main endpoint — the entry point your users actually hit.
• Webhook receivers — if you depend on incoming webhooks (Stripe, GitHub, etc.), monitor the endpoint that receives them.
• Third-party dependencies — if your app depends on an external API, monitor it so you know when their outage is causing your errors.

Building a Good Health Check Endpoint

If your API doesn't have a health check endpoint yet, here are quick examples that actually verify your service is working:

from fastapi import FastAPI
from database import get_connection

app = FastAPI()

@app.get("/health")
async def health_check():
    try:
        conn = await get_connection()
        await conn.execute("SELECT 1")
        return {"status": "ok"}
    except Exception as e:
        return JSONResponse(
            status_code=503,
            content={"status": "unhealthy", "error": str(e)},
        )

const express = require("express");
const db = require("./database");

const app = express();

app.get("/health", async (req, res) => {
  try {
    await db.query("SELECT 1");
    res.json({ status: "ok" });
  } catch (err) {
    res.status(503).json({
      status: "unhealthy",
      error: err.message,
    });
  }
});

Combining Uptime Alerts with Event Notifications

Health checks catch when your service is completely down. But what about errors that happen while the service is still running? A payment endpoint might return 200 to the health checker but fail silently on specific requests.

The best setup combines both:

• Health checks for "is the service reachable?" — handled automatically by NotificationsBot's polling
• Event notifications for "something went wrong inside the service" — sent from your code via the API when you catch an error

import os
import requests

API_KEY = os.environ["NOTIFICATIONSBOT_API_KEY"]

def notify_error(title: str, message: str):
    requests.post(
        "https://api.notificationsbot.com/event",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={
            "channel": "error-alerts",
            "title": title,
            "message": message,
        },
        timeout=5,
    )

# In your payment handler:
try:
    charge = stripe.Charge.create(amount=amount, ...)
except stripe.error.CardError as e:
    notify_error(
        "Payment failed",
        f"User {user_id} — {e.user_message}",
    )

Now you have two layers of monitoring: the health checker catches total outages, and your code catches business logic failures. Both go to the same notification system, reaching the right people on the right platform.

DIY Monitoring vs NotificationsBot

• Setup — DIY: write a script, create a Telegram bot, find your chat ID, deploy to a separate server. NotificationsBot: add a URL in the dashboard
• Reliability — DIY: if your monitoring server goes down, you get no alerts. NotificationsBot: runs on separate infrastructure
• Recovery alerts — DIY: you have to implement them yourself. NotificationsBot: automatic "back up" notifications
• Multi-platform — DIY: one platform per script. NotificationsBot: Telegram + Discord + Slack from the same check
• Multiple URLs — DIY: extend your script for each URL. NotificationsBot: add URLs in the dashboard
• Event history — DIY: build your own logging. NotificationsBot: searchable event log with timestamps

Bonus: Alert the Right People at the Right Time

The most effective uptime monitoring setup separates who gets notified based on severity. A common pattern:

• uptime-alerts channel — Telegram subscriber for the on-call engineer. They get a phone buzz immediately, day or night.
• team-updates channel — Slack or Discord subscriber for the whole team. They see it during work hours.

Your health check sends to uptime-alerts. The on-call engineer gets woken up and fixes it. Then they manually send an update to team-updates with context on what happened. No one gets paged unnecessarily, and the team still stays informed.