Compromiso público y contractual de disponibilidad por plan. La versión auditable de este documento
vive en docs/COMPLIANCE_SLA.md y es la fuente para revisión legal. Esta página se
sirve directamente desde el backend Go y sobrevive a un build roto del frontend.
| Plan | Uptime garantizado | Ventana de medición | Crédito disponible |
|---|---|---|---|
| Scale | 99.5% | Mes calendario | Sí |
| Growth | 99.0% | Mes calendario | Sí |
| Base / Starter | Sin SLA garantizado | — | No aplica |
Para plan Base / Starter ofrecemos best-effort, transparencia operacional en /status y respuesta a incidentes según el mismo playbook que para planes pagos, pero sin compromiso contractual de uptime ni credits.
Si el uptime medido en un mes calendario cae bajo el SLA del plan, el cliente afectado tiene derecho a un credit aplicable al siguiente ciclo de facturación.
Ejemplo: plan Scale con uptime medido 99.3% (0.2% bajo el 99.5% comprometido). El credit corresponde a 20% del MRR de ese mes.
Consideramos downtime cuando se cumplen las dos condiciones simultáneamente:
5xx sostenido.La medición se realiza desde 3 regiones independientes de probes externos: Santiago (CL), São Paulo (BR) y Madrid (ES). Un incidente cuenta como downtime sólo si al menos 2 de las 3 regiones lo detectan en simultáneo. Esto descarta cortes locales de red del cliente o problemas de su propio ISP.
Los logs de los probes se almacenan 13 meses y están disponibles para auditoría externa a solicitud (security@convexiapp.cl).
El credit no es automático para evitar disputas de medición: el cliente lo solicita y nuestro equipo de billing lo valida contra los logs de probes.
Los siguientes eventos no cuentan como downtime y por tanto no generan derecho a credit:
Los cambios al SLA se comunican con al menos 60 días de anticipación a los clientes activos en planes Scale y Growth. Las versiones históricas quedan archivadas en docs/COMPLIANCE_SLA.md con git history completo.