En pocas palabras: Un plugin de detección de fallos corre dentro de WordPress y chequea PHP, base de datos, WP-Cron y WooCommerce, detectando errores silenciosos que un monitor externo ignora: un checkout roto que igual devuelve HTTP 200 OK. El monitor mide disponibilidad; el plugin mide salud real.
Un plugin para detectar fallos en WordPress corre dentro del propio sitio y ve lo que un monitor de uptime externo no puede: un checkout roto que igual devuelve 200 OK, una base de datos que conecta pero responde lento, o un WP-Cron colgado. El monitor externo te avisa que el sitio cayó. El plugin interno te dice por qué cayó.
Un plugin de detección de fallos en WordPress es una extensión que se instala dentro del sitio y ejecuta chequeos de salud sobre PHP, la base de datos, WP-Cron, plugins activos y WooCommerce, para encontrar errores silenciosos que un monitor externo (que solo mira el código de estado HTTP desde afuera) pasa por alto. La diferencia clave es el acceso directo a los internals de WordPress.
En 30 segundos
- Un HTTP 200 no significa que el sitio funcione: la home puede cargar mientras el checkout, el login o el cron están rotos.
- El monitor externo mide disponibilidad; el plugin interno mide salud. Necesitás los dos, no uno.
- Los fallos más caros son silenciosos: errores 500 tapados con try-catch, cart-fragments devolviendo 404, gateways que timeoutean.
- WP-Cron depende de que haya tráfico; si nadie visita el sitio, tareas como backups o emails no se disparan y nadie se entera.
- El plugin te da diagnóstico post-mortem: logs, stack trace y estado de plugins. El monitor externo solo te dice «estuvo caído 15 min».
WooCommerce es un plugin de código abierto para WordPress desarrollado por Automattic que permite crear y administrar tiendas online. Proporciona funcionalidades de carrito de compras, gestión de productos y procesamiento de pagos.
¿Por qué un monitor de uptime no detecta caídas reales?
Porque un monitor de uptime externo hace una sola pregunta desde afuera: «¿responde el servidor?». Si el servidor devuelve un código 200, el monitor marca «todo bien» y sigue de largo. El problema es que WordPress puede devolver 200 con la página a medio armar, con el carrito roto o con la base de datos escupiendo queries que tardan seis segundos cada una. Consulta nuestra guía de talles disponible.
Ponele que actualizás un plugin un viernes a la tarde. La home sigue cargando perfectamente, el monitor externo está contento, vos te vas a tu casa. Lo que no ves es que el panel de administración quedó bloqueado por un fatal error que solo aparece cuando estás logueado, o que el formulario de contacto dejó de mandar mails. El monitor «vio» un sitio online todo el fin de semana. Los clientes vieron otra cosa.
Como resume la gente de live24h, sin monitoreo profesional muchas veces te enterás de la caída «recién cuando el cliente se queja», y para ese entonces el daño ya está hecho. Un plugin, en cambio, corre dentro de WordPress: puede ejecutar la query real, invocar el hook real y confirmar que la acción se completó, cosa que un chequeo HTTP desde afuera nunca va a poder hacer.
¿Qué diferencia hay entre monitoreo interno y externo?
El monitoreo externo vive fuera de tu servidor y te dice si el sitio está caído. El interno vive dentro de WordPress y te dice qué se rompió. Son capas complementarias: si el servidor se apaga entero, el plugin interno se apaga con él y no te avisa nada, así que ahí el externo es imprescindible. Pero para todo lo que falla con el sitio «prendido», el interno es el único que tiene visibilidad.
Acá entra un detalle que muchos ignoran: WP-Cron no es un cron de verdad. Se dispara cuando alguien visita el sitio. Si tenés poco tráfico o el sitio está caído, las tareas programadas (backups, envío de emails, sincronización de stock) no corren, y ningún monitor externo te lo va a marcar porque desde afuera todo se ve verde. Te puede servir nuestra cobertura de consolidar plugins sin sacrificar confiabilidad.
| Aspecto | Monitor externo | Plugin interno |
|---|---|---|
| Dónde corre | Servidores globales, fuera de tu hosting | Dentro de WordPress |
| Qué ve | Código de estado HTTP, tiempo de respuesta | PHP, base de datos, hooks, WP-Cron, plugins |
| Sobrevive a una caída total del server | Sí (por eso te avisa) | No (se cae con el sitio) |
| Detecta checkout roto con 200 OK | No | Sí |
| Diagnóstico post-mortem (logs, stack trace) | No, solo duración de la caída | Sí |
| Para qué sirve | Saber QUE cayó | Saber POR QUÉ cayó |
¿Cuáles son los fallos silenciosos que solo un plugin detecta?
Los fallos silenciosos son errores que no rompen la carga de la página pero sí rompen la funcionalidad. El monitor HTTP los pierde a todos porque el servidor sigue devolviendo 200. Estos son los sospechosos de siempre:
- Errores 500 tapados con try-catch: un plugin captura la excepción, no la loguea y devuelve una página vacía o incompleta. Para el monitor es un 200 impecable.
- Funciones que retornan null sin avisar: una API interna falla, devuelve
null, y la página se renderiza sin ese bloque. Nadie tira error. - Plugin conflictivo que carga pero no funciona: el JS se rompe en consola, el botón no hace nada. El HTML llegó igual.
- Base de datos conectada pero lenta: las queries tardan y el sitio se arrastra. El monitor externo solo lo nota si medís tiempo de respuesta, y aun así no te dice qué query.
- Caché sirviendo una versión vieja: cambiaste un precio hace tres horas y el usuario ve el anterior. Estado 200, contenido incorrecto.
- Certificado SSL a punto de vencer: hoy carga, la semana que viene tira error de seguridad y espanta a medio tráfico.
¿Cómo detecta un plugin los fallos específicos de WooCommerce?
Un plugin engancha directo en los hooks y condiciones de WooCommerce, así que puede verificar el flujo de compra real en vez de mirar la home. Ese es el punto donde el monitoreo genérico se queda corto, porque la tienda puede estar «online» con el checkout muerto.
El caso clásico: actualizás WooCommerce y cart-fragments.js empieza a devolver 404. La home carga bárbaro, el catálogo también, pero el mini-carrito no se actualiza y el checkout se traba. Un monitor apuntado a la portada ve 200 OK y no se entera de nada. Como marca Robotalp en su análisis sobre qué monitorear de verdad en WooCommerce, el uptime de la home dice muy poco sobre si la gente puede comprar.
Otros fallos que un plugin puede vigilar desde adentro: el gateway de pago que timeoutea contra el procesador, el stock que no se sincroniza y sobrevende, o el email de confirmación de pedido que nunca sale porque el SMTP quedó mal configurado. Todos con la tienda «prendida» y el monitor externo en verde. En cuando usas generador de imágenes IA profundizamos sobre esto.
¿Qué información da un plugin que un monitor externo no puede ofrecer?
Un plugin te da el material para el diagnóstico post-mortem: logs de errores de PHP y WordPress, stack trace completo, qué plugins y theme estaban activos y cuál fue la última acción que se completó bien. Con eso reconstruís qué pasó. Un monitor externo, en el mejor de los casos, te dice «el sitio estuvo caído 15 minutos» y ahí termina la película.
La diferencia práctica es enorme. Con el plugin sabés que la caída arrancó justo después de actualizar el plugin X a la versión 3.2, que el error fue un fatal en tal archivo y que la base venía respondiendo lento desde antes. Sin esa data, arrancás a las 11 de la noche revisando a ciegas, desactivando plugins de a uno para ver cuál era. Ya te pasó, seguro.
¿Cómo configuro un monitoreo multicapa que no pierda ningún fallo?
La receta que funciona es apilar capas que se cubran entre sí: una que sobreviva a la caída total y otra que vea los internals. Ninguna sola alcanza. Este es el checklist mínimo: Cubrimos ese tema en detalle en problemas tras actualizar tu WooCommerce.
- Monitor externo cada 1 a 5 minutos: apuntado no solo a la home sino a URLs críticas (checkout, login, un endpoint de la API).
- Chequeos de salud internos: un plugin que verifique PHP, base de datos, WP-Cron y hooks de WooCommerce cada pocos minutos.
- Content-checking además del status code: que el monitor busque una palabra clave en el HTML («Finalizar compra», por ejemplo). Si el 200 llega pero la palabra no está, algo se rompió.
- Alertas en más de un canal: email más Telegram o SMS. Si el mail depende del mismo servidor que se cayó, no te enterás.
- Logs guardados afuera: nunca solo en el servidor que puede caer. Si el disco muere, se va el log con la evidencia.
- Chequeo de SSL y expiración de dominio: avisos con semanas de anticipación, no el día que revienta.
Sobre dónde vive todo esto: la mitad de estos fallos arrancan por el hosting (PHP mal configurado, base saturada, sin soporte de caché a nivel server). Si vas a montar una tienda WooCommerce en serio, un hosting WordPress como el de Donweb te saca de encima buena parte de los dolores de cabeza de infraestructura antes de que lleguen al plugin.
Errores comunes al monitorear WordPress
- Monitorear solo la home: el checkout puede estar muerto y vos festejando 100% de uptime. Corrección: agregá las URLs de compra y login al monitor.
- Confiar solo en el plugin interno: si el server se apaga, el plugin se apaga y no te avisa. Corrección: sumá siempre un monitor externo.
- Un solo canal de alerta: el mail de aviso sale por el mismo servidor caído. Corrección: Telegram o SMS como segundo canal.
- Creer que un 200 es sinónimo de «funciona»: es el error madre. Corrección: verificá contenido, no solo código de estado.
- No mirar los logs hasta que hay incendio: la mayoría de las caídas avisan antes (queries lentas, warnings). Corrección: revisá logs de forma periódica, no reactiva.
Preguntas Frecuentes
¿Qué fallos detecta un plugin que un monitor externo no ve?
Un plugin interno detecta errores 500 tapados con try-catch, funciones que devuelven null, WP-Cron colgado, queries lentas, caché sirviendo versiones viejas y checkout de WooCommerce roto con la home funcionando. Todos comparten algo: el servidor sigue devolviendo un HTTP 200, así que el monitor externo los marca como «sitio online».
¿Por qué mi sitio muestra 200 pero no funciona?
Porque el código de estado 200 solo confirma que el servidor entregó una respuesta, no que esa respuesta sea correcta. WordPress puede renderizar la página con un bloque roto, un JavaScript que falla en consola o un formulario que no envía, y aun así devolver 200. El estado HTTP mide entrega, no funcionalidad.
¿Necesito un plugin y un monitor externo, o alcanza con uno?
Necesitás los dos. El monitor externo sobrevive a una caída total del servidor y te avisa que el sitio se cayó; el plugin interno tiene acceso a los internals de WordPress y te dice qué se rompió. Si el servidor se apaga entero, el plugin se apaga con él, así que uno no reemplaza al otro.
¿Hay plugins gratuitos para monitorear la salud de WordPress?
Sí. El propio núcleo de WordPress trae la herramienta Salud del sitio (en Herramientas > Salud del sitio), que chequea versión de PHP, base de datos, actualizaciones y configuración. Es un buen punto de partida gratuito, aunque no reemplaza a un monitoreo continuo con alertas ni cubre el flujo específico de WooCommerce.
¿Cada cuánto conviene que corran los chequeos?
El monitor externo, cada 1 a 5 minutos, para reducir el tiempo entre la caída y el aviso. Los chequeos internos de salud, cada pocos minutos también, siempre que no sobrecarguen el servidor. La regla es: cuanto más crítico el flujo (un checkout activo), más corto el intervalo.
Conclusión
El cambio de mentalidad es simple pero cuesta: dejar de creer que «el sitio responde» equivale a «el sitio funciona». Un monitor de uptime externo es la primera línea, te avisa cuando todo se apaga. Pero la mayoría de los fallos que te hacen perder ventas no apagan nada: dejan la home intacta y rompen el checkout, el login o el cron por debajo.
Qué hacer ahora, concreto: sumá un plugin de chequeos internos a tu monitor externo, apuntá el monitoreo a las URLs de compra y no solo a la portada, activá content-checking y armá alertas por dos canales distintos. Con esas capas, la próxima caída silenciosa la vas a ver vos primero y no un cliente enojado.
