Estado del servicio, SLA y mantenimiento

Consultar el estado

Dos sondas públicas, anónimas y sin datos de cliente, basadas en los health checks del propio servicio. Responden en la raíz del host de la API (no cuelgan de /api/v1):

Sonda	Qué comprueba	Úsala para
GET /health/live	El proceso responde. No toca base de datos, caché ni cola.	Monitores de uptime externos.
GET /health/ready	Base de datos, caché y bus de mensajes. Resultado cacheado unos segundos.	Saber si las dependencias están operativas.

/health es un alias antiguo de /health/ready.

curl -i https://<host-de-la-api>/health/ready
# HTTP/1.1 200 OK
# {"status":"Healthy","checks":{"Database Connection":{"status":"Healthy","duration":"3"},"Cache":{...}},"totalDuration":"6"}

• status es Healthy, Degraded o Unhealthy. Con Unhealthy el código HTTP es 503; en otro caso 200.
• La respuesta incluye solo el estado y la duración de cada comprobación, nunca descripciones ni excepciones.
• No las sondees más de una vez por minuto desde un mismo monitor.
• Un 503 aislado no es una incidencia; alerta tras varios fallos consecutivos (recomendado: 3 en 3 minutos).

SLA de disponibilidad por plan

Objetivo de disponibilidad mensual de la API y los webhooks salientes:

Plan	Disponibilidad mensual	Tiempo de inactividad máximo al mes
Starter	99,5 %	≈ 3 h 36 min
Growth	99,9 %	≈ 43 min
Enterprise	99,95 %	≈ 21 min
Custom	99,99 %	≈ 4 min

Cómo se mide. Porcentaje de minutos del mes natural en que GET /health/ready responde sin Unhealthy, medido desde fuera de nuestra infraestructura. Quedan excluidos los mantenimientos programados conforme a la política de abajo, los fallos de tu red o de tu integración, la fuerza mayor y los límites propios de la API (429 por cuota o ráfaga).

Webhooks. Los eventos que no se entregan por una caída nuestra se reintentan según lo descrito en Webhooks; una caída tuya no cuenta contra el SLA.

Los porcentajes de esta tabla son los de la tarifa comercial vigente. Las compensaciones por incumplimiento (créditos de servicio) y cualquier compromiso adicional se fijan en tu contrato; ante discrepancia prevalece el contrato.

Ventanas de mantenimiento

Tipo	Aviso	Cuándo	Impacto esperado
Programado	Al menos 7 días antes, por el changelog y email a los administradores de la cuenta	Fuera de horario laboral europeo (preferentemente entre 01:00 y 05:00 UTC)	Interrupción breve; la API puede responder 503 con Retry-After.
Urgente (seguridad o estabilidad)	El máximo posible, sin plazo mínimo	Cuando sea necesario	Se comunica igualmente y sí cuenta para el SLA si supera lo anunciado.

Los despliegues habituales son blue-green y no requieren ventana. Los cambios compatibles descritos en la política de versiones nunca se tratan como mantenimiento.

Qué debe hacer tu cliente

• Ante 503 o 429, reintenta con espera exponencial y respeta Retry-After.
• Usa Idempotency-Key en las escrituras para poder reintentar sin duplicar.
• Verifica la firma de los webhooks y deduplica por la cabecera X-IncentIA-Idempotency-Key: durante un mantenimiento pueden llegar con retraso.