PHP detiene una petición cuando supera el tiempo de ejecución, pero el retraso real puede ser trabajo de CPU, un bloqueo de base de datos, una espera HTTP remota o un lote demasiado grande. Aumentar el número no vuelve eficiente la tarea y quizá exista un timeout anterior en el proxy.
Conserva el primer error fatal y comprueba si la tarea terminó parcialmente antes de volver a ejecutarla.
Registra los límites de la tarea
Anota página o acción, número de elementos, hora de inicio, hora del error y último elemento confirmado. Consulta el archivo y la línea del error fatal.
Compara:
max_execution_time de PHP
timeout del proxy y servidor web
timeout de la API remota
duración de consulta o bloqueo MySQL
duración mostrada por el navegadorUsa registros protegidos y oculta parámetros personales o secretos.
Dibuja la jerarquía de tiempos máximos
Anota el plazo de cada salto: CDN, balanceador, servidor web, PHP-FPM, script PHP, base de datos y API remota. El valor efectivo más pequeño termina la petición visible.
Distingue tiempo total de tiempo de CPU, porque las configuraciones PHP no contabilizan igual todas las esperas de red. Comprueba el comportamiento del alojamiento en lugar de confiar en el nombre del ajuste. Un proceso CLI tiene otra jerarquía y aun así necesita un límite operativo.
Averigua qué hace la línea señalada
El error puede apuntar a un bucle, consulta, operación con archivos o petición de red. Lee el código cercano y la pila de llamadas del componente.
Un timeout dentro de curl_exec() sugiere una dependencia remota; dentro de una función de base de datos puede ocultar una consulta lenta o un bloqueo; en un bucle sobre entradas o imágenes señala el tamaño del lote.
No parches esa línea sin entender sus entradas y quién la llama.
Comprueba efectos parciales
Importaciones, correos, actualizaciones y sustituciones pueden confirmar cada elemento por separado. Cuenta qué cambió e identifica registros con claves estables.
Antes de reintentar, confirma que la operación es idempotente o reanúdala desde un punto de control. Repetir un envío masivo o una escritura externa puede crear duplicados visibles para clientes.
Haz una nueva copia de archivos y datos antes de reparar resultados parciales.
Rastrea esperas MySQL y remotas
Relaciona la petición con registros de consultas lentas, bloqueos y proveedor. Establece tiempos de conexión y lectura acotados en APIs propias.
Un timeout externo deja el resultado en estado desconocido. Consulta al proveedor mediante una referencia estable antes de repetir una escritura.
Evita mantener abierta una transacción MySQL mientras esperas a un servicio externo.
Procesa en lotes acotados
Divide el trabajo en unidades pequeñas y guarda el progreso después de cada lote terminado.
Propiedades del lote:
identificadores explícitos
duración medida
punto de control y reanudación
lista de errores
reintento seguroUtiliza cron o Action Scheduler cuando corresponda, pero vigila la cola. Una acumulación oculta no es una tarea completada.
Prefiere CLI para mantenimiento
WP-CLI evita los plazos del navegador y del proxy y resulta adecuado para importaciones, sustituciones y regeneraciones. Sigue necesitando límites explícitos, registros y reversión.
Ejecuta con el usuario correcto del alojamiento, en la raíz y base de datos previstas. Confirma el entorno antes de cualquier orden destructiva.
No presupongas que cerrar la terminal detiene un proceso desacoplado.
Cambia los tiempos con pruebas
Si la tarea medida es finita, eficiente y no puede dividirse más, ajusta los límites de PHP o servidor mediante controles compatibles durante la ventana de mantenimiento.
Mantén acotadas las peticiones públicas para proteger los workers. Restaura los valores temporales y documéntalos.
Ampliar todas las capas a varios minutos permite que una sola visita ocupe capacidad escasa.
Verifica carga y salud de la web
Ejecuta primero una prueba pequeña y después el lote previsto mientras vigilas duración, memoria, base de datos y workers PHP. Comprueba recuentos y que no haya efectos duplicados.
Prueba páginas públicas durante la operación. El mantenimiento recurrente debería identificar tareas largas antes de actualizar y programarlas con puntos de control; una tarea fiable termina o reanuda de forma determinista, sin depender de un timeout cada vez mayor.