Tu API se cae a las 2 AM. Tus usuarios empiezan a recibir errores. Algunos tuitean al respecto. Te enteras a la manana siguiente cuando revisas Slack y ves un hilo lleno de quejas. Para entonces el dano ya esta hecho — usuarios frustrados, transacciones perdidas y un golpe a la reputacion que toma dias en recuperarse.
La solucion es simple: monitorea tus endpoints y recibe un mensaje de Telegram en el momento en que algo deja de responder. Tu telefono vibra, te conectas por SSH y lo arreglas antes de que la mayoria de los usuarios se den cuenta. Aqui te explico como configurarlo, desde un script DIY hasta una solucion gestionada.
Opcion 1: Un script de monitoreo personalizado (La forma DIY)
El enfoque mas simple es un script que hace ping a tu API en un horario y te alerta cuando recibe una respuesta que no es 200 o se agota el tiempo. Aqui hay una version en Python usando la API de Telegram Bot directamente:
import time import requests API_URL = "https://api.yourapp.com/health" CHECK_INTERVAL = 60 # segundos 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 esta CAIDA — status {r.status_code}") was_down = True else: if was_down: send_telegram("API esta de vuelta ARRIBA") was_down = False except requests.RequestException: if not was_down: send_telegram("API esta CAIDA — conexion fallida") was_down = True time.sleep(CHECK_INTERVAL)
Esto funciona para un solo endpoint. Pero en cuanto necesites monitorear mas de una URL, los problemas se acumulan:
- Necesitas hospedar el monitor. El script necesita correr en algun lugar 24/7. Si esta en el mismo servidor que tu API, se cae cuando tu API se cae.
- Boilerplate de la API de Telegram Bot. Necesitas crear un bot, obtener el token, encontrar tu chat ID y manejar las llamadas HTTP tu mismo.
- Sin alertas de recuperacion. El script de arriba lo maneja, pero muchas implementaciones rapidas olvidan alertar cuando el servicio vuelve a funcionar — asi que no sabes si la correccion funciono.
- Una sola plataforma. Si tu equipo usa Discord o Slack, necesitas codigo separado para la API de cada plataforma.
- Sin historial. No hay registro de cuando ocurrieron las caidas, cuanto duraron o con que frecuencia suceden.
Para monitorear un proyecto personal, un script con cron esta bien. Para servicios en produccion donde el tiempo de inactividad cuesta dinero, necesitas algo mas confiable.
Opcion 2: Health checks integrados (La forma gestionada)
NotificationsBot tiene una funcion de health check integrada. Agregas una URL en el panel y el servicio la consulta cada 60 segundos desde un servidor externo. Cuando el estado cambia — de arriba a abajo, o de abajo a arriba — envia una alerta a todos los suscritos a ese canal, en la plataforma que usen.
El health checker corre en un servidor separado de tu aplicacion. Hace una solicitud HTTP a tu URL cada minuto. Si la respuesta no es 2xx, o si la conexion se agota, marca la URL como caida y notifica a tus suscriptores. Cuando la URL empieza a responder de nuevo, envia una alerta de recuperacion. Recibes tanto la notificacion de "se rompio" como la de "se arreglo" automaticamente.
Sin scripts que escribir, sin bots que crear, sin servidores que mantener para el monitor en si. Solo agregas la URL y eliges quien recibe las alertas.
Configurando monitoreo de uptime con NotificationsBot
- Registrate en app.notificationsbot.com — plan gratuito, sin tarjeta de credito
- Crea un canal (por ejemplo,
uptime-alerts) - Agrega un suscriptor — elige Telegram, Discord o Slack
- Vincula el suscriptor — conecta su cuenta a traves del flujo de onboarding
- Asigna el suscriptor al canal
- Agrega un health check — ingresa la URL que quieres monitorear y asignala al canal
Eso es todo. El servicio empieza a consultar inmediatamente. Cuando tu API se cae, tu telefono vibra. Cuando vuelve a funcionar, recibes un segundo mensaje confirmando que se recupero.
Que monitorear
No todos los endpoints necesitan monitoreo de uptime. Enfocate en los que tienen impacto real cuando se caen:
- Endpoint de health check — una ruta dedicada
/healtho/api/statusque retorna 200 cuando tu servicio esta corriendo. Este es el mas comun y el mas util. - Landing page / sitio de marketing — si tu sitio web esta caido, los clientes potenciales no pueden encontrarte.
- API gateway o endpoint principal — el punto de entrada que tus usuarios realmente usan.
- Receptores de webhooks — si dependes de webhooks entrantes (Stripe, GitHub, etc.), monitorea el endpoint que los recibe.
- Dependencias de terceros — si tu app depende de una API externa, monitoreala para saber cuando su caida esta causando tus errores.
Un buen endpoint de health check no solo retorna 200 — verifica que el servicio realmente puede hacer trabajo. Revisa que la base de datos sea accesible, que los servicios requeridos esten conectados y que la app no este en un estado degradado. Un health check que siempre retorna 200 es peor que no tener health check, porque te da falsa confianza.
Construyendo un buen endpoint de health check
Si tu API aun no tiene un endpoint de health check, aqui hay ejemplos rapidos que realmente verifican que tu servicio esta funcionando:
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, }); } });
Combinando alertas de uptime con notificaciones de eventos
Los health checks detectan cuando tu servicio esta completamente caido. Pero que pasa con los errores que ocurren mientras el servicio sigue corriendo? Un endpoint de pagos podria retornar 200 al health checker pero fallar silenciosamente en solicitudes especificas.
La mejor configuracion combina ambos:
- Health checks para "esta el servicio accesible?" — manejado automaticamente por el polling de NotificationsBot
- Notificaciones de eventos para "algo salio mal dentro del servicio" — enviadas desde tu codigo via la API cuando capturas un 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, ) # En tu handler de pagos: try: charge = stripe.Charge.create(amount=amount, ...) except stripe.error.CardError as e: notify_error( "Pago fallido", f"Usuario {user_id} — {e.user_message}", )
Ahora tienes dos capas de monitoreo: el health checker detecta caidas totales y tu codigo detecta fallos de logica de negocio. Ambos van al mismo sistema de notificaciones, llegando a las personas correctas en la plataforma correcta.
Monitoreo DIY vs NotificationsBot
- Configuracion — DIY: escribir un script, crear un bot de Telegram, encontrar tu chat ID, desplegar en un servidor separado. NotificationsBot: agregar una URL en el panel
- Confiabilidad — DIY: si tu servidor de monitoreo se cae, no recibes alertas. NotificationsBot: corre en infraestructura separada
- Alertas de recuperacion — DIY: tienes que implementarlas tu mismo. NotificationsBot: notificaciones automaticas de "volvio a funcionar"
- Multi-plataforma — DIY: una plataforma por script. NotificationsBot: Telegram + Discord + Slack desde el mismo check
- Multiples URLs — DIY: extender tu script por cada URL. NotificationsBot: agregar URLs en el panel
- Historial de eventos — DIY: construir tu propio logging. NotificationsBot: log de eventos buscable con timestamps
Bonus: Alertar a las personas correctas en el momento correcto
La configuracion de monitoreo de uptime mas efectiva separa quien recibe la notificacion segun la severidad. Un patron comun:
- Canal
uptime-alerts— suscriptor de Telegram para el ingeniero de guardia. Recibe una vibracion en el telefono inmediatamente, de dia o de noche. - Canal
team-updates— suscriptor de Slack o Discord para todo el equipo. Lo ven durante horas de trabajo.
Tu health check envia a uptime-alerts. El
ingeniero de guardia se despierta y lo arregla. Luego envia
manualmente una actualizacion a team-updates con
contexto de lo que paso. Nadie es paginado innecesariamente y
el equipo se mantiene informado.
Enterate cuando tu API se caiga — antes que tus usuarios
Configura una cuenta gratuita, agrega la URL de tu API y empieza a recibir alertas de Telegram en minutos. Sin scripts, sin bots, sin mantenimiento.
Comenzar gratis