Histórico uptime público
Publicamos uptime mes a mes · incidentes documentados · MTTD y MTTR reales · sin maquillaje. Es la única forma honesta de operar SaaS clínico crítico.
Histórico mensual
Datos extraídos de UptimeRobot (polling 60s · 5 monitores) + Sentry (issue tracking) + observabilidad Cloudflare workers analytics. Fuente cruzada · sin manual override.
| Periodo | Target | Actual | Incidentes | Downtime |
|---|---|---|---|---|
Mayo 2026 (parcial · al día 16) Mes en curso · sin incidentes registrados | 99.9% | 100.00% | 0 | 0min |
Abril 2026 Cold-start Cloudflare worker tras deploy · resuelto sin intervención | 99.9% | 99.97% | 1 | 13min |
Marzo 2026 Mantenimiento programado migration 0015 · ventana 03:00 UTC | 99.9% | 99.99% | 0 | 4min |
Febrero 2026 | 99.9% | 100.00% | 0 | 0min |
Enero 2026 (desde día 18 · live) 2 incidentes Meta token rotation · ambos resueltos <30min · postmortem público | 99.5% (early) | 99.92% | 2 | 47min |
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 |
|---|---|---|
| API Worker (Cloudflare) | 99.99% | Operacional |
| Webhook Meta (WhatsApp) | 99.97% | Operacional |
| Webhook Stripe | 100.00% | Operacional |
| Webhook Cal.com | 99.98% | Operacional |
| Supabase database (read) | 99.99% | Operacional |
| Supabase database (write) | 99.96% | Operacional |
| Upstash QStash queue | 99.95% | Operacional |
| Upstash Redis (mutex) | 100.00% | Operacional |
| Landing (Cloudflare Pages) | 99.99% | Operacional |
| Dashboard React | 99.97% | 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.