¿Cómo sabes que tu app se ha caído?

Qué es y por qué importa

Monitorizar una app significa saber que se ha roto antes de que alguien te lo diga. Sin eso, si la web se cae de noche, te enteras por la mañana. Y a menudo nadie te escribe para decírtelo: quien encuentra la app rota la cierra y ya está.

Para mí, la monitorización son tres piezas que trabajan juntas:

• La comprobación desde fuera: un servicio que cada pocos minutos abre tu dirección, como haría un usuario, y mira si responde.
• El registro de errores: el sitio donde acaba cada error de la app, con el stack trace, o sea, la línea de código donde se ha roto.
• El aviso: el correo o la notificación en el móvil que te llega cuando uno de los dos encuentra algo.

La comprobación tiene que estar fuera de tu app: si la app se ha caído, no te lo puede decir ella. El registro de errores, en cambio, te dice qué se rompe aunque la app responda.

Y si conectas Claude Code al registro de errores, cuando salta la alerta no empiezas de cero.

1. Qué uso

Uso dos servicios. No son los únicos: con otros el proceso es el mismo.

Para los errores: Sentry

Cada error de la app llega allí con su stack trace, y de allí salen los avisos. El plan gratuito se llama Developer: es para un solo usuario y manda los avisos por correo.

Para la comprobación cada 5 minutos: UptimeRobot

Abre tu dirección y, si no responde, te avisa por correo y con una notificación en la app del móvil. Plan gratuito: 50 monitores, comprobación cada 5 minutos; las condiciones de uso compruébalas en su web.

2. La media hora

Se hace una sola vez, en más o menos media hora si la app ya está online.

Sentry en la app

1. Crea un proyecto en Sentry. Te enseña el DSN, la clave del proyecto: es la dirección a la que tu app manda los errores. Lo vuelves a encontrar en los ajustes del proyecto, en Client Keys (DSN).
2. Cópialo y escríbele a Claude Code:

Añade Sentry a esta app usando el DSN que te doy, en una variable de entorno y no en el código. Luego lanza un error de prueba y dime cómo compruebo que ha llegado.

El error de prueba es lo que importa: hasta que no lo ves llegar a Sentry, no sabes si funciona. Luego mira en los avisos de Sentry que haya una regla para los errores nuevos.

Una página que comprobar

La portada a veces carga aunque la base de datos esté parada. Por eso a la comprobación le doy una página específica:

Crea una página /health que responda ok solo si la app y la base de datos funcionan.

Cuando algo no va, la página tiene que responder con un código de error. Si muestra una página normal que dice «error», la comprobación la ve abrirse y piensa que va todo bien. Si Claude no lo ha hecho ya, añado:

Si algo no funciona, /health tiene que responder con un código de error, por ejemplo 503, y no debe mostrar detalles internos como contraseñas, direcciones de la base de datos o mensajes de error completos.

La comprobación cada 5 minutos

1. En UptimeRobot, crea un monitor nuevo en [dirección de tu app]/health, con una comprobación cada 5 minutos.
2. Como avisos, activa el correo y la app del móvil, donde inicias sesión con la misma cuenta.
3. Para probarlo, pon un momento una dirección equivocada en el monitor y mira si te llega el aviso. Luego vuelve a poner la buena.

Sentry dentro de Claude Code

Último paso: conectas Sentry a Claude Code con un servidor MCP, para que Claude pueda leer tus errores. En la terminal, lanza esta línea, con los nombres cortos de tu organización y de tu proyecto en Sentry en lugar de TU-ORG y TU-PROYECTO:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/TU-ORG/TU-PROYECTO

La primera vez te hace iniciar sesión en Sentry desde el navegador; si no pasa, escribe /mcp en Claude Code y elige sentry. La conexión solo vale en el proyecto en el que has lanzado la línea.

3. Cuando salta la alerta

Cuando llega el correo o la notificación, abro Claude Code en el proyecto y pego la alerta en este prompt:

Me ha llegado esta alerta: [pega]. Lee el error en Sentry y los logs, y escríbeme en cinco líneas: qué se ha roto, desde cuándo, por qué, y la corrección que propones. No toques nada en producción hasta que te diga ok.

Cinco líneas porque en ese momento necesito entender, no leer. «Desde cuándo» me dice si tiene que ver el último deploy. Y la última frase es la más importante: con la app caída te entran ganas de arreglarlo sobre la marcha, y una corrección equivocada en producción puede hacer más daño que el error.

4. Si lo quieres automático

El paso siguiente es no tener ni que pegar la alerta. Hay dos caminos.

Con una sesión abierta: /loop

La forma sencilla: dejas abierta una sesión de Claude Code, con Sentry ya conectado, y escribes:

/loop 5m mira en Sentry si hay errores nuevos; si los hay, lee el stack trace y escríbeme qué se ha roto y cómo lo arreglarías.

Cada 5 minutos Claude mira Sentry y solo te escribe si encuentra errores nuevos: son unas 288 vueltas al día, así que mantén el prompt corto. Solo funciona con la sesión abierta y el ordenador encendido, y a los 7 días el loop se borra solo.

Con el ordenador apagado: una rutina con trigger API

Una rutina en la nube funciona aunque el ordenador esté apagado, pero con horario arranca como mucho una vez por hora. Para una alerta conviene el trigger API: una dirección web que pone en marcha la rutina cuando la llamas con el token correcto.

Dos cosas que saber antes: las rutinas requieren un plan de pago de Claude y todavía están en vista previa, así que su funcionamiento puede cambiar.

1. En claude.ai/code/routines, haz clic en New routine. El proyecto tiene que estar en GitHub.
2. Añade Sentry como conector en claude.ai/customize/connectors: la conexión que hiciste con claude mcp add vive en tu ordenador y la rutina no la ve. Quita los conectores que no hacen falta: durante la rutina Claude los usa sin preguntar.
3. Como trigger elige API y guarda. Se añade desde la web, no con /schedule.
4. Copia la dirección de la rutina, haz clic en Generate token y copia el token enseguida: solo lo ves una vez.
5. En tu herramienta de avisos, configura una llamada a esa dirección con el token, con el texto de la alerta en el campo text.

El límite: el trigger API necesita el token y unos headers concretos, que encuentras en el ejemplo junto a la dirección. Las herramientas de avisos gratuitas podrían no conseguir llamarlo, así que compruébalo antes en la tuya.

El texto de la alerta llega a la rutina como un dato que leer, no como una orden: en el prompt tienes que decirle tú que investigue. Yo uso este:

Investiga la alerta descrita en el bloque routine-fire-payload. Lee el error en Sentry, mira los commits recientes y escríbeme en cinco líneas: qué se ha roto, desde cuándo, por qué, y la corrección que propones. No toques nada en producción.

La rutina funciona sin pedirte permisos, y el resultado lo encuentras en la sesión que crea cada vez que arranca. Por eso «No toques nada en producción» se queda: ella investiga y propone, tú decides.

Errores comunes

• Comprobar solo la portada: puede cargar aunque la base de datos esté parada, así que haz que se compruebe /health.
• Una /health que responde con una página normal aunque haya un error: haz que devuelva un código de error.
• No probar nada: lanza el error de prueba y un aviso falso, y mira si te llegan.
• Dejar que Claude corrija en producción durante la alerta: pide primero el diagnóstico y la propuesta, y luego decides tú.
• Dar por hecho que la rutina ve el Sentry que conectaste en la terminal: añádelo como conector en claude.ai.

Lista de comprobación

• Sentry en la app, con el DSN en una variable de entorno
• Error de prueba recibido en Sentry
• Página /health que comprueba la app y la base de datos
• Monitor cada 5 minutos en /health, avisos por correo y en el móvil
• Sentry conectado a Claude Code, sesión iniciada
• Prompt de la alerta guardado donde lo encuentres enseguida

Preguntas frecuentes