Cómo Funciona el Sistema de Monitoreo de PingPuffin

Versión: 1.0
Última actualización: 21 de noviembre de 2024

Tabla de Contenidos

Resumen
Intervalos y Frecuencia de Verificación
Detección de Errores
Recuperación y Cambios de Estado
Actualizaciones Manuales
Protección Contra Fallos del Monitor
Sistema de Notificaciones
Actualizaciones Automáticas del Panel
Recopilación y Almacenamiento de Datos
Especificaciones Técnicas
Privacidad y Seguridad
Confiabilidad del Sistema
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 5 minutos vía cron job
✅ Verificación de 2 checks para evitar falsas alarmas
✅ Monitoreo 24/7/365 sin interrupciones
✅ 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 5 minutos.

Programación cron:

*/5 * * * *

Esto significa:

Primera verificación: 00:00, 00:05, 00:10, 00:15, ...
Sin pausas, sin fines de semana, sin días festivos
Todos los monitores verificados en paralelo para eficiencia

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

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 código de estado esperado (típicamente 200-399)
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 basándose en un principio fundamental en el monitoreo de tiempo de actividad:

El Principio: Si el servidor responde con un código de estado HTTP (ej. 403), significa que el servidor está en línea. La protección de Cloudflare bloquea nuestras solicitudes de monitoreo, pero esto no significa que tu sitio esté caído.

HTTP 403 Forbidden: Si tu sitio devuelve 403, pero el servidor realmente responde (sin timeout), esto se detecta automáticamente como protección de Cloudflare y se marca como "Problematic" (estado de advertencia) en lugar de "Down". Esto es porque 403 típicamente indica protección de bots de Cloudflare, y el servidor está realmente en línea (está respondiendo).
HTTP 503 Service Unavailable: 503 solo se trata como "Problematic" si Cloudflare está realmente detectado (encabezados, patrones de cuerpo, o respuesta corta < 1200 bytes). Si no hay detección de Cloudflare, 503 se trata normalmente (puede ser tiempo de inactividad real).

¿Por qué "Problematic" en lugar de "Down"?

Si el servidor responde con un código de estado HTTP, significa que el servidor está en línea. El monitoreo de tiempo de actividad trata sobre disponibilidad - si el servidor responde, está disponible, incluso si hay protección activa. Por lo tanto, se marca como "Problematic" para indicar que hay protección activa, no tiempo de inactividad real.

Opcional: Configurar Cloudflare para Mejor Monitoreo

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

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

Verificación de Integridad del Navegador: Considera desactivar esto para IPs de monitoreo
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
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 el cron
✅ 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

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

Checks Automáticos

Estado DOWN: Después de 2 fallos consecutivos confirmados (~5-10 min)
Estado UP: Instantáneamente cuando el sitio vuelve de DOWN
Otros cambios: Configurable por usuario (redirección, advertencia, etc.)

Checks Manuales

Notificación instantánea: Si el estado cambia en actualización manual
Sin retraso: Omite el umbral de 2 checks

Canales de Notificación

Email

Notificaciones directas por email
Contiene: Nombre del sitio, estado, mensaje de error, marca de tiempo
Contiene enlace al panel para más detalles

Slack

Mensaje al canal o DM configurado
Formateado con colores según el estado (rojo=DOWN, verde=UP)
Incluye enlace directo al monitor

Webhook

Solicitud POST a endpoint personalizado
Payload JSON con todos los detalles
Código de estado, tiempo de respuesta, mensaje de error incluidos
Útil para integración 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

Actualizaciones Automáticas del Panel

Mecanismo de Auto-Actualización

Tu panel se actualiza automáticamente cada 30 segundos sin recargar la página.

Técnico:

El panel se actualiza automáticamente cada 30 segundos
Obtiene los últimos datos de la base de datos mediante llamadas API seguras
NO activa nuevos checks (solo lectura)
Llamadas ligeras para actualizaciones rápidas

¿Qué se Actualiza?

El panel siempre muestra los últimos datos del último check cron:

🎨 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 automática de 2 checks porque solo muestra datos de checks cron, no 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 Esperados Estándar

Los monitores esperan estos códigos por defecto (pueden personalizarse):

2xx Éxito:

200 OK
201 Created
204 No Content

3xx Redirecciones:

301 Moved Permanently
302 Found
307 Temporary Redirect
308 Permanent Redirect

Personalizado:

Puedes configurar qué códigos de estado son aceptables para tu monitor específico
Ejemplo: Aceptar 401 para páginas protegidas con contraseña

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 cron continúa en errores en monitores individuales
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: Vía log de cron 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 del Cron:

Monitoreado: Cada ejecución de cron registrada
Alertas: En ejecución faltante

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