Monitoreo de uptime y observabilidad

Última actualización: Mayo 2026

CAPI usa dos sistemas complementarios para detectar problemas en producción:

Sistema Para qué sirve Quién recibe alertas
Sentry Errores de runtime en frontend y backend (excepciones, stack traces) Equipo de desarrollo
Better Stack Caídas de servicio (HTTP 5xx, timeouts, certificado SSL vencido, base de datos no responde) dr.capi.app@gmail.com

1. Sentry

Captura errores de la app móvil, panel administrativo y Cloud Functions cuando un usuario tropieza con un bug. Útil para diagnosticar fallas funcionales que no necesariamente tiran el servicio.

2. Better Stack — uptime monitoring

Comprueba endpoints públicos cada pocos minutos y dispara alerta por email cuando un servicio deja de responder.

Endpoints monitoreados

Servicio URL Frecuencia Tipo de chequeo
Panel administrativo https://panel.doctorcapi.com 3 min HTTP 200
App de pacientes y doctores https://app.doctorcapi.com 3 min HTTP 200
Backend (API + base de datos) https://us-central1-capideveloper-6078c.cloudfunctions.net/healthCheck 3 min Keyword "status":"ok"
Documentación técnica https://docs.doctorcapi.com 5 min HTTP 200
Manual de usuario https://manual.doctorcapi.com 5 min HTTP 200
Sitio web https://doctorcapi.com 5 min HTTP 200

Política de alerta: confirmación a 60 segundos (evita falsos positivos por hipos de red), email inmediato a dr.capi.app@gmail.com.

Verificación SSL: activa en todos los monitores. Better Stack también alerta antes de que venza un certificado.

Por qué el monitor de backend es “keyword” y no HTTP simple

La Cloud Function healthCheck siempre responde HTTP 200 — incluso si Firestore está caído podría responder 200 con "status":"degraded". Por eso el monitor verifica que el body contenga literalmente "status":"ok". Si Firestore no responde, el body cambia a "status":"degraded" y Better Stack dispara alerta.

3. Cloud Function healthCheck

Endpoint público que verifica conectividad real con Firestore.

URL: https://us-central1-capideveloper-6078c.cloudfunctions.net/healthCheck

Código: Capi-App/firebase/functions/health_check.js

Qué hace:

  1. Ejecuta firestore().collection('clinics').limit(1).get().
  2. Si la lectura tiene éxito, devuelve HTTP 200 con { status: "ok", checks: { firestore: { ok: true, latencyMs: N } } }.
  3. Si falla, devuelve HTTP 503 con { status: "degraded", checks: { firestore: { ok: false, error: "..." } } }.

Por qué es importante: los monitores HTTP simples solo detectan caída del hosting (Firebase Hosting). Esta función detecta caída de Firestore aunque el hosting siga arriba — es la diferencia entre “el panel carga pero no muestra datos” y “el panel está caído por completo”.

Costos: una invocación cada 3 min × 30 días ≈ 14,400 invocaciones/mes. Está dentro del free tier de Cloud Functions (2M invocaciones/mes gratis).

4. Status page pública

URL: https://status.doctorcapi.com (DNS pendiente de configurar — ver más abajo).

URL temporal mientras propaga: https://capi-status.betteruptime.com.

Muestra a clientes (clínicas) el estado en tiempo real de todos los servicios y un historial de 90 días. Útil cuando alguien pregunta “¿está caído CAPI?” — en vez de responder por chat, los pacientes y doctores pueden auto-consultar.

Configuración DNS pendiente

Para que status.doctorcapi.com resuelva, agregar registro CNAME:

class="highlight">
1
2
3
4

Tipo: CNAME
Host: status
Valor: statuspage.betteruptime.com
TTL: 3600

Better Stack provisiona el certificado SSL automáticamente una vez que el DNS resuelve.

5. Cómo agregar un nuevo monitor

Dos opciones:

UI: Better Stack → Monitors → Create monitor → llenar URL + frecuencia + email.

API:

class="highlight">
1
2
3
4
5
6
7
8
9
10
11
12
13

curl -X POST "https://uptime.betterstack.com/api/v2/monitors" \
-H "Authorization: Bearer <TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"url": "https://...",
"pronounceable_name": "Nombre descriptivo",
"monitor_type": "status",
"check_frequency": 180,
"request_timeout": 30,
"confirmation_period": 60,
"email": true,
"verify_ssl": true
}'

Para agregarlo automáticamente a la status page, hacer también POST /api/v2/status-pages/246480/resources con el resource_id devuelto.

6. Qué hacer cuando llega una alerta

  1. Verifica antes de pasar pánico. Abre https://status.doctorcapi.com o el monitor en Better Stack — ¿es solo un endpoint o varios? Si es uno solo y es transitorio, espera 1-2 minutos a la siguiente revisión.
  2. Si es el backend (healthCheck falla), revisa Firebase Console → Firestore → Status. Puede ser caída regional de Google Cloud.
  3. Si es el panel o la app, revisa Firebase Hosting → Releases. Tal vez un deploy reciente rompió algo.
  4. Si es el manual o docs, revisa GitHub Pages status — esas páginas se sirven desde GitHub.
  5. Documenta el incidente en una bitácora interna (esto cubre el requisito LFPDPPP de bitácora de incidentes — ver auditoría COFEPRIS).
This site uses Just the Docs, a documentation theme for Jekyll.