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. 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.
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.