monitoreo de WordPress
Monitoree cada sitio WordPress que gestiona
No hay nada que instalar en el sitio. Uptimepage comprueba cada sitio WordPress desde fuera, en una página que la caché no puede responder en su lugar, y le avisa en Slack o por correo electrónico cuando algo lo rompe, normalmente antes de que el propietario del sitio lo haya notado.
Compruebe una página que la caché no pueda responder
La mayoría de los sitios WordPress tienen una caché de páginas delante de PHP, ya sea de un plugin, del proveedor de hosting o de una CDN. Eso es bueno para los visitantes y malo para el monitoreo: la caché puede seguir sirviendo la página de inicio mientras PHP se ha caído y la base de datos no responde, así que una comprobación de la página de inicio sigue en verde durante toda la caída. Mantenga la comprobación de la página de inicio, porque es lo que ven los visitantes, y añada otra en una página que la caché omita, como /wp-json/, el índice de la API REST. Esa página no puede responder sin PHP y la base de datos, así que, cuando falla, ha fallado WordPress. Si un plugin de seguridad cierra la API REST a los visitantes, responde 401 o 403, lo que sigue demostrando que PHP y la base de datos funcionan, así que configure la comprobación para que espere ese código. Algunos plugins de caché y algunos proveedores de hosting también la guardan en caché; si el suyo lo hace, use cualquier otra página que su caché excluya.
Un 200 no demuestra que sea su sitio
Una página en blanco puede devolver un 200. También la página genérica que pone un registrador tras una renovación olvidada, o un sitio hackeado que redirige al de otra persona. Dé a la comprobación una frase que solo contenga su página real, como el nombre del sitio en el pie de página, y una respuesta sin ella cuenta como caída, sea cual sea su código de estado.
Las actualizaciones se ejecutan cuando nadie mira
Desde WordPress 5.5, los plugins y los temas pueden actualizarse solos, y las actualizaciones en segundo plano se ejecutan dos veces al día, las esté mirando alguien o no. Desde la versión 6.6, WordPress revierte una actualización de plugin que provoca un error fatal. Una actualización que rompe una página sin error fatal sigue publicada, y lo que la detecta es la comprobación del contenido o un flujo de navegador. En un monitor comprobado desde varias regiones, un fallo puntual visto desde una sola región no avisa a nadie por defecto, así que la alerta que recibe trata del sitio y no de una ruta de red defectuosa. Cuando actualice a mano, programe antes una ventana de mantenimiento y las alertas de ese sitio esperarán hasta que termine.
Una tienda que carga pero no puede vender
En una tienda WooCommerce, la página de inicio y las páginas de producto pueden cargar bien mientras una actualización, un plugin de pagos o un cambio de tema ha roto el carrito o la página de pago. Una comprobación de flujo de navegador recorre el camino de un comprador, hasta cada cinco minutos: abre un producto, lo añade al carrito, va a la página de pago y confirma que el botón «Place order» (realizar el pedido) está ahí. Elija un producto con la gestión de inventario desactivada, porque la página de pago basada en bloques reserva el inventario del carrito durante unos minutos cada vez que se carga. Cuando falla un paso, el resultado nombra ese paso, así que sabe que el problema es la página de pago y no todo el sitio. Cuántas comprobaciones de flujo tiene depende del plan.
WP-Cron espera a los visitantes
Las entradas programadas, los plugins de copias de seguridad y las tareas en segundo plano de WooCommerce esperan a WP-Cron, y WP-Cron solo arranca cuando una visita carga WordPress. Las visitas que responde la caché de páginas nunca lo cargan, así que un sitio con caché solo ejecuta WP-Cron en las visitas que la caché no responde. Los sitios que lo desactivan con DISABLE_WP_CRON dependen de un cron del sistema, y esa línea es fácil de perder al migrar de servidor. En cualquier caso, nada da error. La primera señal es una entrada marcada como «Missed schedule» (programación perdida) o una carpeta de copias de seguridad que dejó de crecer hace semanas. Una comprobación heartbeat convierte ese silencio en una alerta: ejecute WP-Cron desde el cron del sistema, envíe un ping a la URL del heartbeat justo después y, cuando los pings se detengan, se enterará.
Los certificados y los dominios caducan sin avisar
La renovación de Let's Encrypt suele romperse después de un cambio de DNS o de una migración de servidor, y nadie lo nota hasta que los navegadores muestran una advertencia. Los dominios de los clientes suelen estar en la cuenta del registrador del propio cliente, pagados con una tarjeta que caducó el año pasado. Una comprobación TLS avisa antes de que caduque el certificado. Fije el aviso unos días por debajo del punto en que se ejecuta su renovación, para que una renovación normal pase en silencio y solo le llegue una fallida. Una comprobación de caducidad de dominio avisa 30 días antes de que termine el registro, lo que deja tiempo para llamar al cliente.
Páginas de estado que sus clientes pueden abrir
Un cliente puede tener una página de estado con su marca y solo sus propios sitios. Los incidentes se publican en ella a medida que fallan las comprobaciones, así que, cuando un cliente pregunte qué pasó anoche, usted le envía un enlace.
Una lista de clientes sin un formulario por sitio
El formulario sirve para los primeros sitios. Para toda una lista de clientes, el proveedor de Terraform, la API REST y el servidor MCP crean los monitores de una sola vez, con las mismas comprobaciones y los mismos canales de alerta en cada uno, y con Terraform la lista vive en un archivo que puede revisar.
Un crontab para el usuario propietario del sitio. Fije el periodo del heartbeat al intervalo del cron, aquí 5 minutos, con 5 minutos de margen
# Primero añada a wp-config.php: define( 'DISABLE_WP_CRON', true );
# Ejecute como el usuario del sitio, no como root: WP-CLI se niega a ejecutarse como root.
URL=https://app.uptimepage.dev/ping/your-token
*/5 * * * * cd /var/www/example.com && /usr/local/bin/wp cron event run --due-now --quiet; curl -fsS -o /dev/null "$URL/$?"
# Hosting compartido sin WP-CLI: ponga esto en el campo de cron del proveedor,
# con el intervalo más corto que permita, y ajuste a él el periodo del heartbeat.
# curl -fsS -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron" && curl -fsS -o /dev/null https://app.uptimepage.dev/ping/your-tokenPreguntas frecuentes
¿Cómo monitoreo un sitio WordPress?
¿Tengo que instalar un plugin de WordPress?
¿Las comprobaciones cada 60 segundos ralentizan el sitio?
Un plugin de seguridad o un firewall bloquea las comprobaciones. ¿Qué hago?
¿Puede monitorear el proceso de pago de WooCommerce?
¿Puede un cliente tener su propia página de estado?
De un vistazo
- Plugin que instalar ninguno, las comprobaciones se ejecutan desde fuera
- Intervalo de comprobación cada 60 s
- Canales de alerta correo electrónico, Slack, Telegram, webhooks y más
- WP-Cron heartbeat desde un cron del sistema
- Avisos de caducidad certificado SSL y dominio
- Precio para empezar gratis, sin tarjeta
Enlaces
- Páginas de estado para agencias
- Monitoreo de tareas cron
- Monitoreo de inicio de sesión en navegador
- Los nueve tipos de comprobación
- «Missed schedule» en WordPress: por qué ocurre
- Su dominio puede caducar mientras su monitor sigue en verde
- Comprobador de certificados SSL
- Añadir la sonda a la lista de permitidos
- Precios y plan gratuito