Cómo Funciona el Sistema de Monitoreo de PingPuffin

Versión: 1.5
Última actualización: 20 de febrero de 2026

Tabla de Contenidos

  1. Resumen
  2. Intervalos y Frecuencia de Verificación
  3. Detección de Errores
  4. Recuperación y Cambios de Estado
  5. Actualizaciones Manuales
  6. Códigos de Estado HTTP Esperados
  7. Protección Contra Fallos del Monitor
  8. Sistema de Notificaciones
  9. Páginas de Estado Públicas
  10. Actualizaciones Automáticas del Panel
  11. Recopilación y Almacenamiento de Datos
  12. Especificaciones Técnicas
  13. Privacidad y Seguridad
  14. Confiabilidad del Sistema
  15. Escenarios Comunes y Ejemplos

Resumen

PingPuffin monitorea endpoints HTTP y HTTPS 24/7 para asegurar que tus sitios web estén disponibles. Nuestro sistema está construido con un enfoque en confiabilidad, precisión y transparencia.

Características Principales

  • ✅ Verificaciones automáticas cada 3 minutos – todos los monitores se verifican en un horario regular
  • ✅ Verificación de 2 checks para evitar falsas alarmas
  • ✅ Monitoreo 24/7/365 sin interrupciones
  • ✅ Notificaciones por email, Slack, SMS, WhatsApp y webhook (tiempo de inactividad, recuperación, advertencias, vencimiento SSL, respuesta lenta)
  • ✅ Alertas de certificado SSL – notificación 8 días y 2 días antes de que venza tu certificado
  • ✅ Alertas de respuesta lenta – opción de aviso cuando tu sitio responde demasiado lento (Ajustes)
  • ✅ Páginas de estado públicas – comparte una página de estado con tu nombre y logo
  • ✅ Recuperación instantánea cuando tu sitio vuelve
  • ✅ Actualizaciones manuales para verificación rápida
  • ✅ Protección contra errores internos en el sistema de monitoreo

Por Qué Importa la Transparencia

Creemos en la apertura sobre cómo funciona nuestro monitoreo. Este documento explica exactamente cómo detectamos el tiempo de inactividad, cómo evitamos falsas alarmas y cómo nos aseguramos de que recibas notificaciones lo más rápido posible cuando hay un problema real.

Intervalos y Frecuencia de Verificación

Verificaciones Automáticas

Todos los monitores activos se verifican automáticamente cada 3 minutos. Las verificaciones se ejecutan en paralelo para que todos tus monitores se comprueben con rapidez y de forma uniforme.

  • Las verificaciones se realizan a intervalos fijos las 24 horas
  • Sin pausas, sin fines de semana, sin días festivos
  • No tienes que hacer nada: el monitoreo funciona automáticamente

Actualizaciones Manuales

Siempre puedes activar una verificación instantánea mediante el botón "Actualizar ahora" en tu panel:

  • Resultado mostrado inmediatamente
  • Omite el umbral de 2 checks para retroalimentación rápida
  • Útil después de despliegues o cambios de configuración

Cobertura

  • Disponibilidad: 24/7/365
  • Verificaciones paralelas: Todos los monitores verificados simultáneamente
  • Timeout: Estándar 30 segundos (configurable)
  • Redirecciones máximas: Hasta 5 solicitudes de seguimiento

Detección de Errores

Sistema de Verificación de 2 Checks

Para evitar falsas alarmas, requerimos 2 fallos consecutivos antes de marcar un sitio como caído.

Cómo Funciona

Primer Fallo (00:00):

  • Contador de fallos establecido en 1
  • Estado permanece sin cambios (ej., UP)
  • No se envía notificación
  • El sistema registra el fallo para monitoreo interno

Segundo Fallo (00:05):

  • Contador de fallos actualizado a 2
  • Estado cambia a DOWN
  • Incidente creado automáticamente
  • Notificación enviada a todos los canales configurados

Tiempo total: ~5-10 minutos desde el primer fallo hasta el estado DOWN.

¿Por Qué 2 Checks?

Los problemas de red transitorios (fallos de DNS, timeouts breves, errores temporales del servidor) ocurren incluso en sitios estables. Al requerir 2 fallos:

  • ✅ Eliminamos falsas alarmas de problemas breves
  • ✅ Confirmamos que hay un problema real
  • ✅ Mejoramos la confianza del usuario en las notificaciones

¿Qué Cuenta como un Fallo?

Las siguientes situaciones se marcan como fallos:

Códigos de Error HTTP

  • Errores 4xx del Cliente: 400, 403, 404, 405, etc. (a menos que se permitan explícitamente)
  • Errores 5xx del Servidor: 500, 502, 503, 504, etc.

Errores de Red

  • Timeout: Sin respuesta dentro del período de timeout (por defecto: 30 segundos)
  • Conexión Rechazada: El servidor rechaza activamente las conexiones
  • Fallo de DNS: No se puede resolver el nombre de dominio
  • Red Inalcanzable: El host no está disponible en la red

Errores SSL/TLS

  • Certificado Inválido: El certificado es inválido
  • Certificado Expirado: El certificado ha expirado
  • Certificado No Confiable: El certificado no es de una CA confiable
  • Desajuste de Nombre de Host: El nombre de host del certificado no coincide con la URL

Tiempo de respuesta lento

  • Tiempo de respuesta sobre umbral: Si has activado “Notificar cuando la respuesta sea lenta” (Ajustes), un chequeo cuenta como fallo cuando el tiempo de respuesta supera tu umbral (5–15 segundos). La misma lógica de 2 chequeos se aplica: dos chequeos lentos consecutivos dan estado down y notificación.

Manejo de Diferentes Tipos de Error

Importante: TODOS los tipos de error cuentan hacia el contador de fallos.

Ejemplo:

Check 1: HTTP 500 → Contador de fallos: 1, Estado: UP (esperando confirmación)
Check 2: Timeout  → Contador de fallos: 2, Estado: DOWN (fallo confirmado)

Razonamiento:

  • Si un servidor cambia entre diferentes tipos de error, indica inestabilidad
  • No es menos serio si cambia el tipo de error
  • Cualquier fallo significa que el sitio no está funcionando correctamente

Recuperación y Cambios de Estado

Recuperación Instantánea

Cuando tu sitio vuelve, reaccionamos inmediatamente – sin umbral de 2 checks para la recuperación.

Flujo de recuperación:

Estado: DOWN
Check 1: El sitio responde con HTTP 200 → Contador de fallos reiniciado, Estado: UP
Resultado: Recuperación instantánea, notificación enviada

¿Por qué recuperación instantánea?

  • ✅ Los usuarios quieren retroalimentación rápida cuando su sitio vuelve
  • ✅ No hay razón para esperar confirmación de que algo funciona
  • ✅ Mejor práctica en monitoreo
  • ✅ Reduce la preocupación y el tiempo de espera

Estados de Estado

🟢 UP (En Línea)

Significado:

  • El sitio responde con un código de estado HTTP esperado (por defecto: 2xx y 3xx habituales)
  • Tiempo de respuesta dentro del rango aceptable
  • No se detectan errores

Notificaciones:

  • Enviadas en recuperación del estado DOWN

🔴 DOWN (Desconectado)

Significado:

  • El sitio falló 2+ checks consecutivos
  • Incidente creado y rastreado
  • Todos los canales de notificación configurados alertados

Duración:

  • Registrada desde el primer check DOWN hasta la recuperación
  • Mostrada en el registro de incidentes con duración precisa

🟡 WARNING (Advertencia)

Significado:

  • El sitio responde pero con advertencias
  • Ejemplos: Tiempo de respuesta lento, desafío de Cloudflare detectado
  • El monitoreo continúa normalmente

Notificaciones:

  • Pueden configurarse por usuario

🔵 REDIRECT (Redirección)

Significado:

  • Redirección permanente (301) detectada a otra URL
  • El sitio es funcional pero la URL ha cambiado
  • Puedes elegir actualizar la URL o continuar monitoreando la original

Notificaciones:

  • Pueden configurarse por usuario

Sitios Protegidos por Cloudflare

Manejo Automático:

PingPuffin maneja automáticamente los sitios detrás de Cloudflare. El comportamiento depende del código de estado HTTP:

5xx (ej. 503 Service Unavailable): Todos los errores de servidor (500, 502, 503, 504, etc.) se marcan siempre como "Down" y generan notificaciones y tiempo de inactividad en el gráfico – incluso cuando la respuesta contiene texto de Cloudflare. Cloudflare suele reenviar el 503 de tu origen y envolverlo en su propia página de error; interpretamos 5xx como que el servicio no está disponible.

4xx (ej. 403 Forbidden, 429 Too Many Requests): Si el servidor responde con 403 o 429 y detectamos Cloudflare (encabezados o contenido), el monitor se marca como "Problematic" (advertencia) en lugar de "Down". Suele indicar protección de bots o límite de tasa de Cloudflare – no podemos saber si tu sitio está realmente caído, solo que la protección bloquea nuestro chequeo.

¿Por qué "Problematic" para 4xx con Cloudflare?

Si recibimos una respuesta HTTP (ej. 403), el servidor es alcanzable. El monitoreo de tiempo de actividad trata sobre disponibilidad – para 4xx con Cloudflare asumimos que la protección bloquea el chequeo, no que el sitio esté caído. Mostramos "Problematic" para que sepas que hay protección activa.

Opcional: Configurar Cloudflare para Mejor Monitoreo

Si deseas evitar el estado "Problematic" para tu sitio protegido por Cloudflare, puedes:

  1. Reglas WAF: Crea una regla que permita solicitudes del User-Agent de PingPuffin:

    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

  2. Verificación de Integridad del Navegador: Considera desactivar esto para IPs de monitoreo

  3. Limitación de Tasa: Ajusta la limitación de tasa para que las solicitudes de monitoreo no sean bloqueadas

IP de Monitoreo de PingPuffin: 188.245.198.146 (para whitelisting si es necesario)

Actualizaciones Manuales

Checks Iniciados por el Usuario

Siempre puedes activar un check instantáneo mediante el botón "Actualizar ahora" en el panel.

Comportamiento:

  • Omite umbral de 2 checks: El resultado se muestra y aplica inmediatamente
  • Actualización de estado instantánea: Si el estado cambia, se actualiza inmediatamente
  • "Última verificación" actualizada: El panel muestra la nueva hora de check al instante; en la vista general puede mostrarse "Actualizado hace un momento" para el monitor que actualizaste
  • Notificación: Enviada si el estado cambia
  • Contador de fallos actualizado: El contador se actualiza según el resultado

Casos de Uso

  • ✅ Verificación rápida después del despliegue de correcciones
  • ✅ Prueba de nueva configuración de monitor
  • ✅ Check de estado instantáneo sin esperar la próxima verificación automática
  • ✅ Depuración de problemas de conexión

Ejemplo:

00:00 - Check automático falla → Contador de fallos: 1, Estado: UP
00:02 - Haces clic en "Actualizar ahora" → Check falla → Estado: DOWN instantáneamente
Resultado: El check manual omite el umbral de 2 checks para retroalimentación rápida

Códigos de Estado HTTP Esperados

Un monitor se considera UP cuando el servidor devuelve un código de estado HTTP que has marcado como aceptable. Por defecto, PingPuffin trata estos códigos como éxito:

Códigos aceptados por defecto

2xx Éxito

  • 200 OK
  • 201 Created
  • 202 Accepted
  • 203 Non-Authoritative Information
  • 204 No Content
  • 205 Reset Content
  • 206 Partial Content

3xx Redirecciones (tras seguir las redirecciones, se evalúa la respuesta final)

  • 301 Moved Permanently
  • 302 Found
  • 303 See Other
  • 304 Not Modified
  • 307 Temporary Redirect
  • 308 Permanent Redirect

Cualquier otro código (p. ej. 4xx o 5xx) se considera fallo a menos que lo añadas explícitamente a los códigos de estado esperados del monitor.

Códigos de estado esperados personalizados

Puedes definir qué códigos cuentan como éxito por monitor. Por ejemplo:

  • 401 Unauthorized para una página de login o protegida que devuelve correctamente "auth required"
  • 403 Forbidden si esa respuesta es la esperada para la URL que monitoreas
  • 404 Not Found solo si monitoreas intencionadamente una página "not found"

Al crear o editar un monitor puedes indicar una lista de códigos esperados separados por comas (p. ej. 200,201,401). Si lo dejas por defecto, se usa la lista completa anterior.

Dónde se aplica

  • Todos los checks de uptime HTTP(S) usan esta regla (verificaciones automáticas y "Actualizar ahora" manual).
  • El estado se determina comparando el código de la respuesta final (tras redirecciones) con tu lista esperada.
  • Consulta Especificaciones Técnicas para timeouts, límite de redirecciones y otros detalles de la solicitud.

Protección Contra Fallos del Monitor

Errores Internos vs. Externos

Es crítico distinguir entre errores en tu sitio y errores en nuestro sistema de monitoreo.

Errores del Sitio (Monitoreados)

Estos errores de tu sitio cuentan como fallos:

  • ✅ HTTP 500 del sitio objetivo → Cuenta como fallo
  • ✅ Timeout conectando al sitio objetivo → Cuenta como fallo
  • ✅ Error de DNS para el dominio objetivo → Cuenta como fallo

Errores del Sistema de Monitoreo (Protegidos)

Estos errores en el código de PingPuffin NO marcan tu sitio como caído:

  • ❌ Excepción PHP en el código de PingPuffin → NO marca el sitio como caído
  • ❌ Error de conexión a la base de datos → NO marca el sitio como caído
  • ❌ Error de lógica interna → NO marca el sitio como caído

Alertas del Administrador

Cuando el sistema de monitoreo falla:

Registro:

  • Errores críticos registrados con stack trace completo
  • Marca de tiempo e ID del monitor registrados
  • Todos los detalles guardados para depuración

Alarma por Email:

  • Email enviado al administrador del sistema
  • Contiene mensaje de error, stack trace y contexto
  • Limitado por tasa: Máximo 1 email por hora por error único
  • Previene inundación de emails durante problemas del sistema

Base de Datos:

  • El estado permanece sin cambios (sin falsos downs)
  • No se crea incidente
  • Los usuarios no se ven afectados

Ejemplo:

El verificador del monitor se ejecuta
→ Error interno detectado en el sistema de monitoreo
→ Error registrado con contexto completo
→ Email enviado al administrador del sistema
→ Base de datos NO actualizada
→ El estado de tu sitio permanece sin cambios

Sistema de Notificaciones

Cuándo se Envían las Notificaciones

  • Tiempo de inactividad (DOWN): Tras 2 fallos consecutivos confirmados (~5–10 min)
  • Recuperación (UP): Al instante cuando tu sitio vuelve de DOWN
  • Advertencia y redirección: Configurable por usuario (redirección, advertencia)
  • Respuesta lenta: Si lo has activado en Ajustes – dos checks lentos consecutivos dan estado DOWN y notificación
  • Certificado SSL por vencer: Te avisamos 8 días antes y 2 días antes del vencimiento (mismos canales que el resto de notificaciones)
  • Actualización manual: Notificación al instante si el estado cambia al hacer clic en "Actualizar ahora"

Canales de Notificación

Puedes activar uno o más canales en Integraciones (Apps). Todos los canales activados reciben los mismos eventos (tiempo de inactividad, recuperación, vencimiento SSL, respuesta lenta, etc.).

Email

  • Notificaciones directas por email
  • Incluye: nombre del sitio, estado, mensaje de error, marca de tiempo y enlace al panel

Slack

  • Mensaje al canal o DM configurado
  • Formateado con colores (rojo = caído, verde = en línea) y enlace al monitor

SMS

  • Mensaje corto a tu número móvil por tiempo de inactividad, recuperación, vencimiento SSL y respuesta lenta
  • Requiere añadir y activar SMS en Integraciones

WhatsApp

  • Mensaje a tu número de WhatsApp por tiempo de inactividad, recuperación, vencimiento SSL y respuesta lenta
  • Requiere añadir y activar WhatsApp en Integraciones

Webhook

  • Solicitud POST a tu endpoint con JSON (estado, tiempo de respuesta, mensaje de error, etc.)
  • Útil para integrar con otros sistemas

Pausa de Notificaciones

Puedes desactivar temporalmente las notificaciones (pausar) por 24 horas:

Durante la Pausa:

  • ✅ El monitoreo continúa normalmente
  • ✅ Las actualizaciones de estado en el panel
  • ❌ No se envían notificaciones a ningún canal
  • ⏰ Automáticamente se reanuda después de 24 horas

Casos de Uso:

  • Mantenimiento planificado
  • Problema conocido durante el despliegue
  • Cierre temporal

Páginas de Estado Públicas

Para cada monitor (o grupo) puedes mostrar una página de estado pública que cualquiera puede abrir sin iniciar sesión. La página muestra el estado actual (en línea/caído/advertencia) e historial.

  • Personalización: Puedes definir un nombre para mostrar y un logo (URL) para el grupo, para que la página de estado refleje tu marca. Los cambios se aplican tanto en el panel como en la página pública.
  • Idioma: La página de estado puede mostrarse en danés, inglés o español (según la configuración del visitante).
  • Compartir el enlace: Obtienes un enlace estable a la página de estado para compartir con usuarios o incrustar en tu sitio.

Actualizaciones Automáticas del Panel

Mecanismo de Auto-Actualización

Tu panel se actualiza automáticamente cada 30 segundos con los últimos datos y no activa nuevos checks: siempre ves el estado más reciente sin recargar la página.

¿Qué se Actualiza?

El panel siempre muestra los últimos datos de la última verificación automática:

  • 🎨 Indicador de estado: Badge de color (verde/rojo/amarillo/azul)
  • ⏰ Última verificación: Marca de tiempo precisa del último check
  • ⚡ Tiempo de respuesta: Tiempo de respuesta en milisegundos
  • 🔢 Contador de fallos: Número de fallos consecutivos
  • 📊 Información de incidentes: Incidentes activos y duración

Importante: La auto-actualización respeta la lógica de 2 checks porque solo muestra datos de las verificaciones automáticas; no activa nuevos checks.

Recopilación y Almacenamiento de Datos

Registros de Checks

Cada check individual se guarda en la base de datos con la siguiente información:

  • ID único para el check
  • Referencia al monitor
  • Marca de tiempo (cuándo se realizó el check)
  • Código de estado HTTP o tipo de error
  • Tiempo de respuesta en milisegundos
  • Estado de éxito/fallo
  • Mensaje de error (si es relevante)
  • Información de redirección (si es relevante)
  • Detalles de error SSL (si es relevante)

Uso:

  • Cálculos de porcentaje de tiempo de actividad
  • Gráficos y reportes históricos
  • Análisis de errores y depuración
  • Seguimiento de rendimiento a lo largo del tiempo

Seguimiento de Incidentes

Cuando el estado cambia a DOWN, se crea un incidente con los siguientes datos:

  • ID único para el incidente
  • Referencia al monitor
  • Marca de tiempo de inicio
  • Marca de tiempo de fin (cuando se resuelve)
  • Duración total

Características:

  • Creación automática en estado DOWN
  • Cálculo continuo de duración
  • Resolución automática en recuperación
  • Historial completo mantenido
  • Exportable a CSV

Registro de Actividad

Todos los eventos significativos se registran:

  • ✅ Cambios de estado (UP → DOWN, DOWN → UP, etc.)
  • ✅ Checks manuales realizados por usuarios
  • ✅ Cambios de configuración
  • ✅ Actualizaciones de URL
  • ✅ Actualizaciones de metadatos

Funcionalidad:

  • Exportable a formato CSV
  • Buscable y filtrable
  • Muestra detalles para cada evento
  • Marcas de tiempo en todas las entradas

Especificaciones Técnicas

Parámetros de Solicitud HTTP

Cuando PingPuffin verifica tu sitio, se envía la siguiente solicitud:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: */*
Connection: close
[Opcional: Header de Authorization para Basic Auth]

Nota: Usamos un user agent estándar de Chrome para evitar ser bloqueados por sitios que filtran user agents personalizados.

Configuración:

  • Timeout: Puede configurarse por monitor (por defecto: 30 segundos)
  • Seguir Redirecciones: Sí, hasta 5 redirecciones máximo
  • Verificación SSL: Habilitada (valida certificados)
  • Reutilización de Conexión: Deshabilitada (conexión nueva para cada check)

Códigos de Estado HTTP Esperados

Los monitores consideran un check exitoso cuando el estado de la respuesta está en la lista de códigos de estado esperados de ese monitor. Por defecto aceptamos un conjunto amplio de códigos 2xx y 3xx. Para la lista completa y cómo personalizarla, ver Códigos de Estado HTTP Esperados.

Medición del Tiempo de Respuesta

Qué se Mide:

  • Tiempo de búsqueda DNS
  • Tiempo de conexión (handshake TCP)
  • Tiempo de handshake SSL (si HTTPS)
  • Tiempo hasta el primer byte (TTFB)

Qué NO se Mide:

  • Tiempo de descarga del cuerpo (solo leemos headers)
  • Tiempo de ejecución de JavaScript
  • Tiempo de carga de recursos

Almacenamiento:

  • Medido en milisegundos
  • Guardado en cada check
  • Usado para seguimiento de rendimiento
  • Mostrado en el panel

Configuración Avanzada de Monitoreo

Para usuarios avanzados, ofrecemos:

Método HTTP

  • GET: Método estándar
  • POST: Para endpoints que requieren POST

Cuerpo de Solicitud

  • Enviar JSON o datos de formulario con solicitudes POST
  • Útil para endpoints de API que requieren datos específicos

Autenticación Básica

  • Nombre de usuario y contraseña para endpoints protegidos
  • Contraseñas encriptadas con AES-256-CBC
  • Nunca almacenadas en texto plano

Características Futuras

  • Headers personalizados
  • Parámetros de solicitud
  • Autenticación avanzada (OAuth, Bearer tokens)

Información del Servidor

Dirección IP Pública

El servidor de monitoreo de PingPuffin usa la siguiente dirección IP pública para realizar checks:

Dirección IP: 188.245.198.146

Si necesitas incluir la dirección IP de PingPuffin en la lista blanca de tu firewall o configuración del servidor, puedes usar esta dirección IP.

Nota: La dirección IP puede cambiar durante migraciones de servidor o actualizaciones de infraestructura. Recomendamos usar el header User-Agent para identificación en lugar de reglas basadas en IP, si es posible.

Identificación User-Agent:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Privacidad y Seguridad

Encriptación de Datos

Credenciales Sensibles:

  • Todas las contraseñas (Basic Auth) encriptadas en almacenamiento
  • Algoritmo: AES-256-CBC (estándar de la industria)
  • Clave: Almacenada de forma segura en variables de entorno
  • IV: Vector de inicialización único por encriptación
  • La desencriptación solo ocurre en memoria durante los checks
  • Nunca expuesta en logs o respuestas API

Acceso a Datos

Control de Acceso:

  • Resultados de checks solo visibles para el propietario del monitor
  • No se comparten datos con terceros
  • Registro de actividad solo exportable por el propietario
  • Endpoints API seguros con autenticación

Seguridad de Base de Datos:

  • Declaraciones preparadas (previene inyección SQL)
  • Autenticación basada en sesión
  • Protección CSRF en todos los formularios

Aplicación de HTTPS

SSL/TLS:

  • Todos los checks de monitor soportan HTTPS
  • Validación de certificado SSL habilitada
  • Advierte sobre problemas de certificado
  • Detecta certificados expirados

Panel:

  • Siempre accedido vía HTTPS
  • Cookies seguras (flags HttpOnly, Secure)
  • Headers HSTS recomendados

Confiabilidad del Sistema

Salud del Sistema de Monitoreo

Nuestro sistema de monitoreo se monitorea a sí mismo:

Detección de Errores:

  • Detección automática de errores internos
  • Registro completo de todas las excepciones
  • Stack traces para depuración

Alertas del Administrador:

  • Errores críticos enviados por email al administrador del sistema
  • Limitado por tasa para evitar spam
  • Detalles incluidos para resolución rápida

Recuperación Automática:

  • El sistema continúa comprobando el resto de monitores aunque falle uno
  • Sin fallos en cascada entre monitores
  • Las transacciones de base de datos aseguran integridad de datos

Objetivos de Tiempo de Actividad

Buscamos la siguiente confiabilidad:

Tiempo de Actividad del Sistema de Monitoreo:

  • Objetivo: 99.9% (menos de 9 horas de inactividad por año)
  • Monitoreado: Mediante registros internos y métricas del sistema

Tasa de Ejecución de Checks:

  • Objetivo: 99.5% de tasa de éxito para ejecución de checks
  • Monitoreado: Tasa de error en logs

Confiabilidad de las verificaciones: El monitoreo se ejecuta de forma continua; ante problemas técnicos se alerta al administrador para mantener el sistema estable.

Escenarios Comunes y Ejemplos

Escenario 1: Problema de Red Transitorio

Situación: Problema breve de red, el sitio está realmente en línea.

00:00 - Check falla (timeout) → Contador de fallos: 1, Estado: UP
00:05 - Check tiene éxito → Contador de fallos: 0, Estado: UP

Resultado:
✅ No se envía notificación
✅ No hay cambio de estado
✅ No hay falsa alarma

Por qué funciona: El umbral de 2 checks captura problemas breves.

Escenario 2: Tiempo de Inactividad Real

Situación: El servidor está realmente caído (ej., problema de hosting).

00:00 - Check falla (HTTP 500) → Contador de fallos: 1, Estado: UP
      → El sistema registra el primer fallo para monitoreo interno

00:05 - Check falla (timeout) → Contador de fallos: 2, Estado: DOWN
      → Incidente creado automáticamente
      → Notificación enviada vía email/Slack/webhook

00:10 - Check falla (timeout) → Contador de fallos: 3, Estado: DOWN
      → Duración del incidente actualizada continuamente

Resultado:
✅ Estado DOWN confirmado a las 00:05
✅ Notificación enviada ~5 minutos después del primer fallo
✅ Diferentes tipos de error (500 + timeout) ambos cuentan

Por qué funciona: Dos fallos consecutivos confirman un problema real.

Escenario 3: Recuperación Rápida

Situación: Sitio caído, vuelve rápidamente.

00:00 - El estado es DOWN (de fallo anterior)
00:05 - Check tiene éxito (HTTP 200) → Contador de fallos: 0, Estado: UP
      → Incidente marcado como resuelto automáticamente
      → Notificación de recuperación enviada

Resultado:
✅ Recuperación instantánea en el primer check exitoso
✅ Duración del incidente calculada (00:00 a 00:05 = 5 min)
✅ Eres informado rápidamente sobre la recuperación

Por qué funciona: No hay umbral de 2 checks para recuperación.

Escenario 4: Actualización Manual Durante el Primer Fallo

Situación: Check automático falló una vez, el usuario quiere verificar.

00:00 - Check automático falla → Contador de fallos: 1, Estado: UP
      → El estado permanece UP (esperando confirmación)

00:02 - Haces clic en "Actualizar ahora" → Check falla → Estado: DOWN inmediatamente
      → El check manual omite el umbral de 2 checks para retroalimentación rápida
      → Notificación enviada

Resultado:
✅ El check manual da retroalimentación instantánea
✅ El estado se actualiza sin esperar el próximo check automático
✅ Útil para depuración y verificación

Por qué funciona: Los checks manuales están diseñados para retroalimentación instantánea.

Escenario 5: Error del Sistema de Monitoreo

Situación: Error interno en el propio código de PingPuffin.

00:00 - El sistema de monitoreo ejecuta check automático
      → Error interno detectado
      → Error capturado automáticamente

      Registro:
      → Error registrado con contexto completo para monitoreo interno
      → Información técnica completa guardada para depuración

      Alarma del Administrador:
      → Email enviado al administrador del sistema (máx. 1 por hora)
      → Contiene detalles del error y contexto

      Base de Datos:
      → No hay actualización al estado de tu sitio
      → El estado de tu sitio permanece sin cambios
      → El contador de fallos no se ve afectado

Resultado:
✅ El error del monitor NO afecta el estado de tu sitio
✅ El administrador alertado para arreglar el problema
✅ No hay estado DOWN falso

Por qué funciona: Distinción entre errores del monitor y errores del sitio.

Escenario 6: Diferentes Tipos de Error Consecutivamente

Situación: Servidor inestable, diferentes errores cada vez.

00:00 - Check falla (HTTP 500) → Contador de fallos: 1, Estado: UP
00:05 - Check falla (Timeout de conexión) → Contador de fallos: 2, Estado: DOWN
00:10 - Check falla (HTTP 503) → Contador de fallos: 3, Estado: DOWN

Resultado:
✅ Diferentes tipos de error TODOS cuentan
✅ Estado DOWN después de 2 fallos (independientemente del tipo)
✅ Indica servidor inestable (tal vez peor que un error consistente)

Por qué funciona: Cualquier error significa que el sitio no está funcionando correctamente.

Preguntas Frecuentes

¿Qué tan rápido recibo notificación de tiempo de inactividad?

Check automático: ~5-10 minutos después del primer fallo (requiere 2 fallos).
Check manual: Instantáneamente si actualizas manualmente.

¿Puedo recibir falsas alarmas?

Muy raramente. El sistema de 2 checks elimina la mayoría de los problemas breves. Si recibes una alarma, casi siempre hay un problema real.

¿Qué pasa si mi servidor es temporalmente lento?

Si el tiempo de respuesta excede el timeout (por defecto 30 seg), cuenta como fallo. Puedes aumentar el valor de timeout para tu monitor.

¿Cómo se maneja el mantenimiento planificado?

Usa la función "Pausar" para desactivar notificaciones por 24 horas. El monitoreo continúa, pero no recibes alarmas.

¿Puedo ver el historial de todos los checks?

Sí, el registro de actividad muestra todos los checks y cambios de estado. También puedes exportar a CSV.

¿Qué pasa si PingPuffin mismo se cae?

Nuestros monitores se ejecutan en infraestructura confiable. En errores críticos del sistema, el administrador es alertado, pero tu sitio NO se marca como caído.

Contacto y Soporte

¿Tienes preguntas sobre cómo funciona el monitoreo?

📧 Email: support@pingpuffin.com
🐛 Reportes de errores: Vía email
📚 Documentación: Ver sección de documentación para más información

Registro de Cambios

v1.5 (20 de febrero de 2026)

  • SMS y WhatsApp añadidos como canales de notificación (en Integraciones)
  • Alertas de certificado SSL: notificación 8 días y 2 días antes del vencimiento (todos los canales)
  • Alertas de respuesta lenta: opción de aviso cuando el sitio responde demasiado lento (Ajustes, 5–15 seg)
  • Páginas de estado públicas: descrita la personalización con nombre para mostrar y logo, e idiomas
  • Detalles técnicos de implementación eliminados de la documentación para usuarios (enfoque en lo que ves y puedes configurar)

v1.3 (14 de febrero de 2026)

  • Actualización de versión y fecha de documentación

v1.2 (9 de febrero de 2026)

  • Nueva sección: Códigos de Estado HTTP Esperados con lista por defecto completa (200, 201, 202, 203, 204, 205, 206, 301, 302, 303, 304, 307, 308) y personalización
  • "Actualizar ahora" manual: documentado el feedback de "Última verificación" y "Actualizado hace un momento" en el panel

v1.1 (17 de enero de 2026)

  • Las verificaciones se ejecutan en paralelo (mayor rapidez)
  • Intervalo de check reducido de 5 a 3 minutos
  • Cada categoría puede verificar hasta 200 monitores por ejecución
  • Documentación actualizada con detalles de procesamiento en paralelo

v1.0 (21 de noviembre de 2024)

  • Primera versión de documentación
  • Sistema de verificación de 2 checks implementado
  • Protección contra fallos del monitor agregada
  • Alertas del administrador limitadas por tasa

Este documento se actualiza continuamente. Revisa "Última actualización" en la parte superior para ver si hay nuevas versiones.

📅 Última actualización: 01 de March de 2026 • ⏱️ Hace 1 días