Estado del servicio
Lo que ha medido el monitor externo desde el y la última respuesta de /health, la dirección que pide para saber si el servicio está en pie. Cada cifra sale del registro del monitor o de esa respuesta.
- Estado
- Vigente
- Última revisión
- 30 sep 2026
Última comprobación de /health
Sin fallos en los 3 componentes que prueba /health; los otros 6 no los prueba.
Respuesta generada el a las 15:49 (hora peninsular) · HTTP 200. Esta página vuelve a pedirla como mucho cada 5 minutos. La respuesta en bruto está en /health (se abre en otra pestaña).
| Componente | Resultado |
|---|---|
| Worker de Cloudflare (/health)Diagnóstico agregado; no prueba cada ruta del Worker ni que el asistente conteste. | Prueba correcta |
| Base de datos (Supabase)Una lectura de prueba desde /health; no cubre todas las consultas. | Prueba correcta274 ms |
| WhatsApp Business (Meta)Entrada y envío de mensajes y aprobación de plantillas. | No lo prueba /healthEstado que publica el proveedor (se abre en otra pestaña) |
| Modelos de lenguaje (OpenAI)Respuestas, transcripción de audios y búsqueda en la información de la clínica. | No lo prueba /healthEstado que publica el proveedor (se abre en otra pestaña) |
| Pagos (Stripe)Cobro de las cuotas de las clínicas; hoy no hay pago en línea ni cobro de señales. | No lo prueba /healthEstado que publica el proveedor (se abre en otra pestaña) |
| Agenda (Cal.com)Disponibilidad y creación de citas. | No lo prueba /healthEstado que publica el proveedor (se abre en otra pestaña) |
| Caché y bloqueos (Upstash Redis)Un ping desde /health; no comprueba la cola de mensajes. | Prueba correcta103 ms |
| Registro de errores (Sentry)Captura de errores del Worker. | No lo prueba /healthEstado que publica el proveedor (se abre en otra pestaña) |
| Web pública (Vercel)Esta web; /health no la comprueba. | No lo prueba /healthEstado que publica el proveedor (se abre en otra pestaña) |
3 de 9 componentes tienen resultado en esta prueba. La latencia es la de una sola petición, no una media. De los demás no publicamos un estado propio: enlazamos el que publica su proveedor.
Disponibilidad medida
Del al , /health estuvo caído 9 h 1 min en 176,0 días observados.
Disponibilidad de /health en todo el periodo99,79 %176,0 díasMedido (registrado por un sistema)| Mes | Disponibilidad | Frente al objetivo del 99,5 % |
|---|---|---|
| abr 2026Caído: 6 h 26 min en 23,5 días observados | 98,86 % | Por debajo |
| may 2026Caído: nada en 31,0 días observados | 100,00 % | Cumple |
| jun 2026Caído: nada en 30,0 días observados | 100,00 % | Cumple |
| jul 2026Caído: nada en 31,0 días observados | 100,00 % | Cumple |
| ago 2026Caído: 1 h 47 min en 31,0 días observados | 99,76 % | Cumple |
| sep 2026Caído: 47 min en 29,6 días observados | 99,89 % | Cumple |
Cómo leer la tabla
El objetivo se mide en ventanas móviles de 30 días; aquí se agrupa por mes natural para que cualquiera pueda rehacer la cuenta. Abril sólo cuenta desde el alta del monitor, y el último mes, hasta la fecha de consulta. No se descuenta nada: tampoco las caídas de proveedores, que los objetivos de servicio excluyen.
Caídas registradas
El monitor ha registrado 16 caídas, que se agrupan en 4 episodios. La más larga empezó el a las 02:37 y duró 6 h 26 min (HTTP 503). No hay informe publicado de ninguna.
| Inicio | Causa documentada |
|---|---|
| Fin: Tiempo caído: 6 h 26 min en 1 caída (HTTP 503) | Sin análisis publicado. |
| Fin: Tiempo caído: 1 h 42 min en 10 caídas (HTTP 503) | Upstash Redis dejó de responder a ratos y /health lo traduce a 503. Se corrigió esa misma noche. |
| Fin: Tiempo caído: 5 min en 1 caída (HTTP 503) | Probable. Consultas a la base de datos que se agotaron en cascada; la saturación del proveedor no está confirmada. |
| Fin: Tiempo caído: 47 min en 4 caídas (HTTP 503) | Sin análisis publicado. |
Medido (registrado por un sistema)Monitor externo de UptimeRobot número 802785868. Horas peninsulares; cada duración tiene un margen de hasta 5 minutos.
Tareas programadas
Que /health responda no garantiza que las tareas programadas (avisos internos, limpieza de datos, reintentos) estén corriendo. Por eso hay un segundo monitor, desde el , que pide el latido de esas tareas y da error si llevan demasiado tiempo sin ejecutarse.
Ha registrado 24 caídas, que suman 21 h 37 min en 91,8 días observados: una disponibilidad del 99,02 %. La más larga empezó el y duró 5 h 45 min. La última es del .
Cómo se mide
- UptimeRobot pide /health cada 5 minutos. Una caída más corta no se ve, y cada duración puede desviarse hasta 5 minutos.
- Antes del no había monitorización: de ese periodo no hay datos. El monitor no anota su arranque, así que entre el alta y la primera caída cuenta el tiempo como disponible.
- Que /health responda bien no prueba que el asistente conteste a un paciente: prueba que el servidor responde y que alcanza la base de datos y la caché. Una vez estuvieron 23 tareas programadas cinco horas sin ejecutarse mientras /health decía que todo iba bien.
- Una caída es que /health respondió con error o no respondió. No distingue si el fallo era nuestro o de un proveedor: esta página no descuenta nada.
- El registro del monitor se leyó el a las 15:16. Hasta la siguiente lectura, lo que haya pasado después no sale aquí; la comprobación de /health de arriba sí se renueva sola.
Objetivos
Los objetivos de disponibilidad y de soporte, y lo que no cubren, están en objetivos de servicio. Nada de esta página acredita que se cumplan: sólo cuenta lo que ha pasado.