Abre la zona → pestaña Health Checks en my.cubepath.com.
Un health check sondea el destino de un registro y saca su IP del DNS cuando deja de responder, devolviéndola automáticamente cuando se recupera. Eso es toda la función: ningún panel que vigilar, ninguna alerta que atender — la dirección muerta simplemente deja de repartirse.
NotaLos health checks funcionan solo en registros A y AAAA, uno por registro. El failover consiste en descartar una dirección muerta del conjunto de respuestas, lo que solo tiene sentido cuando el valor del registro es una dirección que se puede sondear. Además son una función Pro/Business: en una zona Free la pestaña muestra un aviso de mejora en lugar de su contenido.
Añadir un check
- 1Pulsa Add health checkEl selector de registros lista los A y AAAA que todavía no tienen check.
- 2Ponle nombreAlgo que reconozcas en la lista:
api uptime,edge eu-west. - 3Elige el tipoHTTPS (por defecto), HTTP, TCP o PING.
- 4Ajusta los tiemposIntervalo, timeout y los dos umbrales. Los valores por defecto son razonables; lee la tabla de abajo antes de tocarlos.
- 5GuardaEl check empieza a sondear de inmediato y muestra unknown hasta tener resultados suficientes.
Ajustes
| Ajuste | Por defecto | Rango | Notas |
|---|---|---|---|
| Target | El propio valor del registro | — | Un host o IP a secas: sin esquema, sin ruta, sin espacios. Sobrescríbelo solo para sondear otro endpoint |
| Port | — | 1–65535 | Obligatorio en TCP, opcional en HTTP/HTTPS |
| Path | / | — | Solo HTTP/HTTPS, debe empezar por / |
| Expected status | 200 | 100–599 | Solo HTTP/HTTPS. Cualquier otro código cuenta como fallo |
| Interval | 60 s | 10–3600 | Cada cuánto sondeamos |
| Timeout | 5 s | 1–60 | Mantenlo bastante por debajo del intervalo |
| Healthy after | 2 | 1–10 | Éxitos consecutivos antes de devolver la IP al DNS |
| Unhealthy after | 3 | 1–10 | Fallos consecutivos antes de retirarla |
| Enabled | Activado | — | Desactiva un check sin borrarlo. Deja de facturarse mientras está apagado |
Elegir el tipo de comprobación
- HTTPS/HTTP con una ruta es el único tipo que te dice que la aplicación está viva. Apúntalo a un endpoint de salud real que toque lo que importa — si
/healthdevuelve 200 con la base de datos caída, el check te está mintiendo. - TCP demuestra que un puerto acepta conexiones. Es lo adecuado para bases de datos, colas de mensajes y todo lo que no sea HTTP.
- PING demuestra que el host responde a ICMP. Es la señal más débil: una máquina puede responder al ping con todos sus servicios muertos. Úsalo cuando no haya nada mejor.
Estados
Un check informa de healthy (su IP se está sirviendo), unhealthy (ha fallado suficientes veces seguidas, su IP no se sirve) o unknown (se creó hace demasiado poco para haber hecho suficientes sondeos). Un check desactivado aparece como Disabled y no afecta al DNS en absoluto.
La lista muestra cada check junto a su registro, el valor y la región del registro, el destino que se sondea y el intervalo — que es justo la vista que quieres cuando varios registros regionales tienen su propio check.
Cómo de rápido es el failover en realidad
Se suman dos retardos, y solo uno es nuestro:
- Detección:
unhealthy after×intervalo. Con los valores por defecto, tres fallos de 60 segundos son hasta tres minutos. - Propagación: el TTL del registro, porque los resolvers siguen sirviendo la respuesta cacheada independientemente de lo que nosotros sepamos.
ConsejoMantén el TTL en 30–60 segundos en cualquier registro con health check, y no pongas el intervalo muy por debajo del TTL — sondear cada 10 segundos mientras los resolvers cachean una hora no te aporta nada. Mira Registros para las pautas de TTL.
Apretar los umbrales acorta la detección pero vuelve el check más nervioso: unhealthy after 1 retira un servidor de rotación por un solo paquete perdido. Dos o tres fallos es el compromiso habitual.
Facturación
Cada health check cuesta 10 $/mes, prorrateado. La facturación se detiene en cuanto lo desactivas o lo borras — borrarlo pide confirmación y tiene efecto inmediato.
Diagnóstico
| Síntoma | Causa probable |
|---|---|
| La pestaña muestra un aviso de mejora de plan | La zona está en el plan Free; los health checks requieren Pro o Business |
| El registro no aparece en el selector | No es un registro A/AAAA, o ya tiene un check |
| "Un health check TCP requiere puerto" | Añade el puerto |
| Se rechaza el target | El target debe ser un host o IP a secas — quita https://, la ruta y los espacios |
| "La ruta debe empezar por '/'" | Añade la barra inicial |
| El estado se queda en unknown | Aún no se han hecho suficientes sondeos; dale unos cuantos intervalos |
| Unhealthy pero el servidor está bien | El sondeo no llega: un firewall bloqueando nuestras comprobaciones, ICMP descartado, o un endpoint HTTP que devuelve algo distinto del código esperado |
| La IP muerta se sigue sirviendo | Aún no ha pasado la detección más el TTL, o el TTL del registro es demasiado alto |
Para la foto completa de enrutar entre regiones y hacer failover dentro de ellas, mira GeoDNS.