WordPress funciona bien casi todo el día, pero a una hora parecida las páginas tardan, el administrador se detiene o el checkout responde peor. Después se recupera sin cambios manuales.
Un patrón horario suele señalar capacidad compartida: tráfico, copias, WP-Cron, colas de correo, importaciones, análisis de seguridad u otra cuenta del servidor. Revisar el hosting cuando ya se ha recuperado no basta; hay que alinear las pruebas con el intervalo lento.
Construir una cronología
Durante varias incidencias registra inicio y final con zona horaria, URL y acciones afectadas, impacto público o administrativo, tráfico, recursos PHP/MySQL, tareas próximas, errores y recuperación automática.
«Cada mañana» es impreciso. Diez minutos desde las 02:05 sugieren algo distinto de dos horas durante la actividad comercial. No reinicies servicios como primera reacción salvo que la disponibilidad lo exija: podrías borrar el estado que identifica el recurso saturado.
Medir durante el problema
Comprueba de forma ocasional una URL representativa:
curl -s -o /dev/null
-w '%{time_starttransfer} %{time_total} %{http_code}n'
https://example.com/No ejecutes un bucle agresivo. Si varios documentos sencillos muestran primer byte alto, busca trabajo compartido del servidor. Si el HTML sigue rápido pero falla una función, inspecciona su petición Ajax o externa.
Comparar tráfico y límites
La misma hora puede coincidir con la llegada de clientes. Revisa analítica respetuosa con la privacidad o peticiones del servidor: solicitudes totales y sin caché, bots, transacciones, búsquedas, accesos y descargas.
El tráfico solo se convierte en problema cuando agota procesos PHP, CPU, memoria, conexiones MySQL, disco o una cuota externa. No bloquees por volumen sin distinguir una campaña legítima de abuso.
En hosting compartido, exporta la gráfica del intervalo. cPanel puede mostrar límites de CPU, memoria, procesos de entrada, I/O o concurrencia. Una captura posterior a la recuperación es una evidencia débil.
Revisar WP-Cron y tareas del panel
Lista eventos vencidos o próximos:
wp cron event list
--fields=hook,next_run_gmt,next_run_relative,recurrenceBusca tareas junto al retraso, *hooks* duplicados, eventos atrasados, frecuencias anómalas y procesos de grandes conjuntos de datos. No elimines lo desconocido: puede controlar correos, stock, copias o limpieza.
Aunque cPanel, Plesk o el servidor ejecuten WP-Cron de forma real, varias tareas pesadas pueden coincidir. Revisa cron del panel, copias, análisis, importaciones, feeds y WooCommerce Action Scheduler. Escalona trabajos independientes sin romper dependencias.
Analizar copias y seguridad
Una copia lee miles de archivos, comprime, consulta MySQL y sube un archivo. Puede agotar el disco aunque la CPU parezca normal. Compara hora de inicio y fin, volumen incluido, compresión, espacio temporal, subida remota, solapamientos y copias antiguas locales.
No desactives la única copia funcional. Ajusta horario, alcance, método incremental o almacenamiento después de demostrar la relación.
Los análisis de malware también consumen archivos, base de datos e I/O. Relaciona sus registros con el intervalo y busca reintentos. Reprograma o ajusta sin eliminar cobertura necesaria.
Comprobar WooCommerce, correo e importaciones
Action Scheduler gestiona correos, *webhooks*, suscripciones y stock. Revisa acciones pendientes y fallidas; cuando exista la herramienta:
wp action-scheduler action list
--status=pending
--per-page=20No ejecutes ni canceles en masa sin conocer el efecto comercial. Una cola creciente puede ser causa o consecuencia de la saturación.
Los boletines, avisos de pedidos, formularios e informes pueden abrir muchas conexiones SMTP. Si se envían de forma síncrona, el visitante espera. Lleva campañas grandes a un sistema apropiado y conserva correctamente el correo transaccional.
Feeds de productos, exportaciones, índices e informes pueden golpear MySQL cuando la base crece. Mide tiempo y filas examinadas. Corrige índices, rangos o recalculados; no borres pedidos históricos para disimular una consulta deficiente.
Reconocer procesos PHP agotados
Cuando todos los procesos están ocupados, las peticiones nuevas esperan. El primer byte sube incluso con CPU moderada si los procesos aguardan a MySQL o una API.
Revisa trabajadores activos, cola, registro de peticiones lentas, duración, llamadas HTTP, bloqueos y conexiones. Aumentar procesos sin suficiente memoria o base de datos puede empeorar el fallo.
Verificar una causa cada vez
Si el incidente es breve, recopila automáticamente hora, estado HTTP, respuesta, recursos y comienzo o fin de trabajos, sin registrar datos personales ni URL secretas.
Después mueve una copia, escalona cron, limita un lote, repara una cola, optimiza una consulta, cambia el análisis o añade capacidad justificada. Observa el siguiente intervalo: la relación se fortalece si el retraso se desplaza con la tarea o desaparece.
Para una evaluación aporta zona horaria, dos o tres intervalos, URL, gráficas y horarios conocidos, además del impacto en formularios o checkout. No envíes contraseñas. El resultado debe demostrar el cuello compartido precisamente cuando antes fallaba.