La mayoría de monitores te dicen que el sitio está caído. Site Agent te dice qué plugin acaba de actualizarse, qué administrador acaba de iniciar sesión, qué error fatal acaba de saltar y qué pasarela de WooCommerce ha empezado a devolver 500 — justo ahí en la incidencia, en la misma página que la caída.
Cada caída de WordPress que he depurado se ha reducido a "qué cambió justo antes de esto" — un plugin se auto-actualizó, cambió un tema, un administrador editó la página principal, PHP soltó un fatal en un release nuevo. Sin línea de tiempo, te metes por SSH y empiezas a hacer grep. Site Agent corre dentro de WordPress, captura cada señal operativa según ocurre y muestra la respuesta al lado de la alerta.
Cada evento es una sola fila con marca de tiempo, una frase humana ("Plugin actualizado: WooCommerce v9.4.2 → v9.4.3 por admin@…"), una severidad y los metadatos para actuar.
Instalación, activación, desactivación, actualización y borrado — con versiones antigua/nueva, quién lo disparó y el slug del plugin. "WooCommerce se auto-actualizó de 9.4.2 a 9.4.3 a las 03:14" es una sola fila en la línea de tiempo.
Cambios de tema activo y actualizaciones de tema — la causa más común de tickets "la página principal se ve rota" después de un deploy en viernes.
Cada actualización de core se captura con versión origen/destino, así que una regresión causada por core tiene una fila a la que señalar en lugar de una conjetura.
Capturados a través del shutdown handler de WordPress con archivo:línea y una pista de atribución a plugin/tema/core. Los fatales en contexto de checkout en sitios WooCommerce tienen su propia severidad, así que un carrito que falla silenciosamente deja de ser silencioso.
Nuevo usuario admin, admin borrado, cambios de rol, inicios de sesión de admin — con IP hasheada para que puedas ver "el admin inició sesión desde una IP nueva a las 02:11" sin almacenar direcciones en claro.
Ráfagas de logins fallidos por IP, detección de IP de admin vista por primera vez, cambios de opciones sensibles (siteurl, home, admin_email, default_role, users_can_register) y un barrido diario de wp-config comprobando deriva en DISALLOW_FILE_EDIT y WP_DEBUG_DISPLAY.
Muestras rodantes de duración de petición, pico de memoria y número de consultas en peticiones de admin y cron. Los eventos de petición lenta y presión de memoria saltan cuando una petición cruza umbrales configurables.
Eventos de cron atrasados, detección de DISABLE_WP_CRON y avisos de heartbeat estancado — para que un cron mal configurado deje de ser la razón silenciosa por la que tus emails diarios no salen.
Pedidos fallidos, errores de pasarela de pago, fallos de validación de checkout, fatales de checkout y avisos del system status de WC — sin ningún dato de cliente, pedido o carrito. Solo salud operativa.
Diff diario de los archivos de core de WordPress contra los checksums de api.wordpress.org y diffing por hash de archivos de plugins. Acotado a un presupuesto seguro por ejecución para que la comprobación nunca dispare la carga. Desactivado por defecto; un clic para activarlo.
Una instantánea compacta cada pocos minutos: versión de WordPress, versión PHP, tema activo, número de plugins, estado de WooCommerce, límite de memoria, tendencia de rendimiento. Se muestra como una tarjeta "estado actual" en vivo en Monitrova junto a la línea de tiempo.
Opcional: las últimas N líneas de wp-content/debug.log se escanean buscando notices, warnings y trazas de PHP, y se publican como eventos de baja severidad — útil para detectar errores que no rompen la petición de forma fatal pero indican que algo va mal.
Cuando un sitio cae a las 03:14, este es el tipo de fila que Monitrova muestra en la página de la incidencia — junto al chequeo de uptime que falló.
Uncaught Error: Call to undefined method WC_Cart::get_basket()
en wp-content/plugins/some-plugin/includes/cart.php:142 — atribuido a some-plugin v3.7.1.
some-plugin se auto-actualizó de v3.7.0 a v3.7.1 por wp-cron. Causa raíz probable.
admin@… inició sesión desde una IP hasheada no vista antes para este sitio. Capturado para el rastro de auditoría; no requiere acción salvo que sea inesperado.
WordPress 6.7.2 · PHP 8.2.18 · WooCommerce activo · tema twentytwentyfour-child · pico de memoria 84 MB / 256 MB · 47 consultas · marca de petición lenta activa.
Diseñado por un desarrollador que opera sitios WooCommerce y se niega a instalar plugins que exfiltran datos de clientes.
El agente emite cero HTML en el frontend. No inyecta JS, no añade nodos al DOM, no hace llamadas HTTP extra durante la petición del visitante. Heartbeats, reintentos de cola y escaneos de debug-log corren en WP-Cron, fuera de la ruta crítica.
Por defecto el agente hashea cada IP y User-Agent con SHA-256 antes de enviar. Contraseñas, cookies, tokens de sesión, datos de pedido, email de cliente, contenido de carrito — nunca se recogen. Pasa Plugin Check / cumplimiento wp.org sin problemas.
Los envíos fallidos van a una cola local acotada (máximo 100 elementos) y reintentan vía WP-Cron cada 5 minutos. Cada evento se intenta como mucho 5 veces. Una caída de Monitrova no puede inundar tu base de datos con backlog.
Los tokens se guardan como hash SHA-256 en Monitrova — el secreto en claro se muestra una sola vez al crearlo y no es recuperable. Cada petición de ingesta se verifica contra la URL del sitio para la que se emitió el token, así que un token pegado en la instalación de WordPress equivocada se rechaza con HTTP 403 y un error claro site_url_mismatch.
El plugin es un único ZIP construido bajo demanda por tu propia instancia de Monitrova, así que la versión que descargas siempre coincide con la plataforma a la que envías.
Requiere WordPress 5.6+ y PHP 7.4+. WooCommerce se detecta en tiempo de ejecución — solo recibes el flujo de señales de WooCommerce si el plugin está activo. Multisite está soportado.
No. Uptime, SSL y salud de la página principal funcionan en todos los planes, incluido Free — el agente es puramente aditivo. Añádelo en los sitios WordPress donde quieras una línea de tiempo de cambios internos junto a las sondas externas.
Site Agent está incluido desde Starter en adelante. El plan Free muestra lo que Site Agent capturaría, con un botón de mejora de plan a un clic. Ver la página de precios para la comparación completa de planes.
No tiene impacto medible en las peticiones de frontend. El agente emite cero HTML en el frontend, no engancha wp_head/wp_footer, y empuja todo el trabajo pesado (heartbeat, reintentos de cola, escaneo de debug-log, comprobación de integridad) a WP-Cron. Los umbrales de petición lenta son configurables por el operador.
Los fatales en contexto de checkout llevan su propia etiqueta de severidad para que un fallo silencioso de carrito deje de ser silencioso. Las señales operativas de WooCommerce (pedidos fallidos, errores de pasarela, fallos de validación de checkout, avisos del system status de WC) se capturan sin ningún dato de cliente, pedido o carrito — solo salud operativa.
Los eventos van a una cola local acotada (máximo 100 elementos) y reintentan cada 5 minutos vía WP-Cron, hasta 5 intentos por evento. Una caída de Monitrova no puede llenar tu base de datos con miles de filas pendientes.
El plugin se distribuye directamente desde tu instancia de Monitrova — build bajo demanda, versión emparejada con la plataforma a la que envías. Eso mantiene cliente y servidor sincronizados y evita el backlog de revisión de wp.org. El código pasa Plugin Check limpiamente, así que un listado en wp.org está en el roadmap si hay demanda.
Empieza gratis con uptime, SSL y salud de página principal. Sube a Starter cuando quieras la línea de tiempo de WordPress que convierte cada alerta en "esto es lo que cambió".