Histórico uptime público
Publicamos sólo lo que el monitor externo puede acreditar, con la fecha en que empezó a medir y la caída de seis horas del 12 de abril a la vista. Un histórico que no se puede contrastar no vale nada · y uno sin caídas, menos.
Histórico mensual
Datos de UptimeRobot (300 s de sondeo · 2 monitores, ambos sobre endpoints /health del Worker) + Sentry para el seguimiento de errores. La tabla se mantiene a mano contra esas fuentes: si un dato de aquí no se puede contrastar con ellas, es que no debería estar.
| Periodo | Target | Actual | Incidentes | Downtime |
|---|---|---|---|---|
Desde 2026-04-07 (alta del monitor) · ventanas de 7/30/90 días Ratios que UptimeRobot mantiene hoy para este monitor (100.000-100.000-100.000). La caída de abril queda fuera de esas ventanas por antigüedad, pero se documenta abajo. | 99.5% (objetivo · ver /sla) | 100.00% | 0 | 0 min |
2026-04-12 · incidente registrado HTTP 503 desde las 00:37Z hasta las 07:03Z (23.189 s según el log del monitor). Es la única caída registrada desde que hay medición. En un mes de 30 días equivale al 99,11%. | — | 6 h 26 min caído | 1 | 6 h 26 min |
Antes del 2026-04-07 No había monitorización externa. No publicamos cifras de un periodo que nadie midió: cualquier número aquí sería inventado. | — | sin datos | 0 | sin datos |
Componentes · uptime 90d rolling
Cada componente del stack tiene monitor independiente. Un fallo en uno no necesariamente afecta a otros (arquitectura modular · Cloudflare + Supabase + Upstash desacoplados).
| Componente | Uptime 90d | Estado |
|---|---|---|
| Worker · endpoint /health (monitor 802785868 · desde 2026-04-07) | 100.00% | Operacional |
| Worker · endpoint /health/cron (monitor 803409917 · desde 2026-06-30) | 100.00% | Operacional |
| Webhooks (Meta · Stripe · Cal.com) · sin monitor propio | sin medir | Operacional |
| Supabase · Upstash · Vercel · sin monitor propio (dependemos del status del proveedor) | sin medir | Operacional |
Metodología · cómo medimos
UptimeRobot polling cada 60 segundos contra 5 endpoints health (`/health` Worker · landing · dashboard · status page · webhook reachability). Downtime se cuenta desde el primer fallo confirmado por 2 polls consecutivos (evitar falsos positivos). Mantenimiento programado anunciado >72h NO cuenta como downtime (ver SLA exclusions).
Tiempo entre el inicio real del incidente (timestamp más temprano en logs · si reconstruible · si no UptimeRobot first-fail) y la primera alerta enviada (Sentry email + Slack founder + SMS). Mínimo teórico 30s (frequencia Sentry) · máximo 60s (polling UptimeRobot).
Tiempo entre primera alerta y restauración confirmada del servicio (2 polls UptimeRobot consecutivos verdes · 0 nuevos errores Sentry · health endpoint 200). Incluye tiempo founder reacción · diagnóstico · fix · deploy · verificación.
Esta página se actualiza manualmente cada semana cruzando 3 fuentes (UptimeRobot · Sentry · Cloudflare analytics). Si hay discrepancia >1%, se documenta en el postmortem correspondiente. Pre-revenue · sin presión comercial para maquillar números.
¿Trabajas en DSO o grupo clínico?
Si tu compliance officer necesita SLA contractual firmado o auditoría técnica detallada, hablamos. Pre-Enterprise damos visibilidad completa sin contrato; Enterprise contractualizamos SLA específico al volumen y criticidad.