---
title: "Health Checks"
description: "Sondea el destino de un registro por HTTP, HTTPS, TCP o ping y saca su IP del DNS automáticamente cuando falla: ajustes, estados, tiempo real de failover y precio."
category: "Despliegue"
language: es
source: https://cubepath.com/es/docs/products/despliegue/dns-health-checks-es
updated: 2026-08-08
---

# Health Checks

Abre la zona → pestaña **Health Checks** en [my.cubepath.com](https://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.

> Nota: Los 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

```steps
### Pulsa Add health check
El selector de registros lista los A y AAAA que todavía no tienen check.

### Ponle nombre
Algo que reconozcas en la lista: `api uptime`, `edge eu-west`.

### Elige el tipo
**HTTPS** (por defecto), **HTTP**, **TCP** o **PING**.

### Ajusta los tiempos
Intervalo, timeout y los dos umbrales. Los valores por defecto son razonables; lee la tabla de abajo antes de tocarlos.

### Guarda
El 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 `/health` devuelve 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:

1. **Detección**: `unhealthy after` × `intervalo`. Con los valores por defecto, tres fallos de 60 segundos son hasta tres minutos.
2. **Propagación**: el **TTL** del registro, porque los resolvers siguen sirviendo la respuesta cacheada independientemente de lo que nosotros sepamos.

> Consejo: Manté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](/docs/products/despliegue/dns-records-es) 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](/docs/products/despliegue/dns-geodns-es).