Monitoreo de uptime
Método de la petición
GET o POST. POST te permite comprobar un endpoint que solo acepta escrituras (por ejemplo, la propia comprobación de salud de un receptor de webhooks).
Comprobaciones de puerto TCP
No todo habla HTTP: una base de datos, un servidor de correo, un servidor de juegos. Introduce tcp://host:puerto como URL en lugar de http(s)://, y Dumza comprobará si ese puerto acepta una conexión en vez de hacer una petición HTTP. El método, el código de estado esperado, la palabra clave y el umbral de tiempo de respuesta no aplican a una comprobación TCP y se ocultan en el formulario; las alertas, los incidentes y todo lo demás funcionan exactamente igual.
Código de estado esperado
Cualquier endpoint que devuelva un código distinto al esperado se considera caído. Esto no se limita a 200 — muchas APIs devuelven correctamente 201, 204, o incluso 401/503 en una comprobación saludable (un endpoint que SE SUPONE que debe exigir autenticación, por ejemplo). Configura el estado que devuelve tu endpoint cuando realmente está saludable.
Comprobación de palabra clave
Opcionalmente puedes exigir (o prohibir) un fragmento de texto concreto en algún lugar del cuerpo de la respuesta — útil para endpoints que devuelven 200 incluso cuando algo dentro de la página está roto (un CMS que sirve una página de error genérica con estado 200, por ejemplo). Elige "contiene" para exigir el texto, o "no contiene" para fallar cuando aparece (útil para detectar un aviso de modo mantenimiento que tu app sigue mostrando con estado 200).
Umbral de tiempo de respuesta
Define un tiempo de respuesta máximo aceptable; una comprobación que responde correctamente pero demasiado lento se marca como "degradado" en lugar de "caído" — es visible en tu panel y se cuenta en tus estadísticas de uptime, pero NO abre un incidente ni envía una alerta. Degradado es una señal a vigilar, no algo por lo que avisar a nadie con urgencia.
Intervalo de comprobación
Cada cuánto comprueba Dumza el endpoint. El plan gratuito comprueba cada 5 minutos; los planes de pago pueden bajar hasta cada 1 minuto. Un intervalo más corto significa una detección más rápida de una caída, a costa de más peticiones contra tu servidor.
Ritmo de las alertas: notifyAfter y reenvíos
"Alertar tras N fallos consecutivos" controla cuántas comprobaciones fallidas seguidas abren un incidente (mínimo 2, para evitar falsas alarmas por un único fallo puntual). Por separado, "reenviar alerta cada N minutos" (opcional, mínimo 30) repite la notificación mientras el monitor siga caído — útil si a tu equipo se le pasa la primera alerta.
Significado de los estados del monitor
up (activo) — la última comprobación se superó. down (caído) — hay un incidente abierto. degraded (degradado) — responde, pero más lento que tu umbral de tiempo de respuesta, o más lento que 10 segundos si no has definido ninguno. Un monitor degradado no abre incidencias ni envía alertas. pending (pendiente) — aún no se ha ejecutado ninguna comprobación (recién creado, o en pausa). auth_error (error de autenticación) — el token de acceso de un monitor con credenciales fue rechazado; consulta Monitoreo autenticado.
Por qué falló una comprobación
El registro de comprobaciones del monitor tiene una columna «Causa» que indica el motivo concreto del fallo, con el error técnico en bruto debajo. Las categorías: el dominio no se resolvió (DNS — el nombre ya no apunta a ningún sitio), conexión rechazada (no hay nada escuchando en ese puerto), conexión cerrada inesperadamente, host inaccesible, certificado TLS caducado, certificado TLS no confiable, certificado TLS emitido para otro dominio, fallo en el handshake TLS, tiempo de espera agotado (sin respuesta en 30 segundos), demasiadas redirecciones, código de estado inesperado, falló la comprobación de palabra clave y más lento que tu umbral. Las comprobaciones registradas antes de septiembre de 2026 pueden mostrar un guion: con lo que se guardó entonces no es posible determinar el motivo.
Pausar un monitor
Un monitor en pausa deja de comprobarse por completo y cualquier incidente abierto se cierra automáticamente — no seguirá alertándote por algo que has puesto fuera de servicio deliberadamente (mantenimiento planificado, retirada de servicio). Reanúdalo cuando quieras para retomar el monitoreo.