El error “Maximum execution time exceeded” en XAMPP es una de esas cosas que te revientan el día. Estás probando un script, todo va bien, y de repente la pantalla se queda en blanco o te suelta el fatal error. No es magia negra: PHP tiene un límite de tiempo para ejecutar cada script y, cuando lo peta, corta por lo sano. Por defecto son 30 segundos, y en XAMPP ese valor viene tal cual. Si tu código tarda más, adiós.
La buena noticia es que se arregla en dos minutos y sin dramas. La mala es que mucha gente lo parchea sin entender qué está pasando y luego se le acumulan los problemas. Así que vamos a desmenuzarlo bien.
Qué significa realmente el fatal error maximum execution time
Cuando ves el mensaje Fatal error: Maximum execution time of 30 seconds exceeded, PHP te está diciendo que un script ha superado el tiempo máximo de ejecución permitido. No es un fallo de XAMPP en sí, es una protección del propio PHP para que un script pesado no bloquee el servidor indefinidamente.
Esto se nota sobre todo en importaciones grandes, procesos con bucles anidados, consultas SQL mal optimizadas o llamadas a APIs externas que se quedan colgadas. El fatal error maximum execution time xampp aparece justo en ese momento y te obliga a mirar debajo del capó.
Dónde está el archivo php.ini en XAMPP y cómo tocarlo
El archivo php.ini es el panel de control de PHP. En una instalación típica de XAMPP lo tienes en C:xamppphpphp.ini. Si has instalado XAMPP en otra ruta, búscalo ahí. Ábrelo con Notepad++ o VS Code, mejor que con el bloc de notas de Windows.
Busca la línea max_execution_time = 30 y cámbiala por algo más generoso. Yo suelo poner 300 para desarrollo, que son cinco minutos. Si estás en producción esto no se hace, pero en local con XAMPP es perfectamente razonable:
max_execution_time = 300
Guarda el archivo y cierra. Ojo, porque a veces hay más de un php.ini dando vueltas (por ejemplo, en la carpeta phpMyAdmin hay otro). Si el cambio no surte efecto, comprueba que estás editando el correcto.
Reinicia Apache: el paso que casi todos olvidan
Aquí es donde mucha gente se queda atascada. Tocan el php.ini, recargan la página y sigue el error. ¿Por qué? Porque Apache no relee la configuración de PHP hasta que lo reinicias. Abre el panel de control de XAMPP, para Apache y vuelve a arrancarlo. Sin eso, el maximum execution time en XAMPP seguirá apareciendo como si no hubieras hecho nada.
Si estás en Linux o Mac, desde terminal es tan simple como sudo /opt/lampp/lampp restart. En Windows, botón Stop y luego Start. Nada más.
set_time_limit: la solución para un script concreto
Hay casos en los que no puedes o no quieres tocar el php.ini global. Por ejemplo, si estás en un hosting compartido o si solo necesitas que un script puntual aguante más. Para eso existe set_time_limit, que se pone al principio del archivo PHP:
set_time_limit(300);
Esto afecta únicamente a ese script y sobreescribe el valor del php.ini. Es útil para importadores, generadores de PDFs o tareas de mantenimiento. Eso sí, no lo pongas en el header global de tu aplicación porque entonces estás desactivando la protección en todas partes y eso es pedir problemas.
Errores que se esconden detrás del tiempo de ejecución
Subir el límite tapa el síntoma, pero muchas veces el problema real es el código. Bucles infinitos, consultas SQL sin índices, llamadas a APIs sin timeout, procesamiento de imágenes en bruto… Todo eso dispara el fatal error maximum execution time una y otra vez hasta que optimizas.
Mi consejo: antes de subir el límite a 3600, revisa qué está tardando. Usa microtime(true) para medir bloques, activa el log de consultas lentas en MySQL y mira si hay un bucle que no termina nunca. En el 80% de los casos el problema no es el tiempo, es el código.
Ajustes complementarios que conviene revisar
- max_input_time: controla cuánto se puede tardar en parsear los datos de entrada. Si subes max_execution_time, súbelo también.
- memory_limit: a veces el script muere por memoria antes que por tiempo. Ponlo en 256M o 512M si trabajas con datos grandes.
- post_max_size y upload_max_filesize: si estás subiendo archivos enormes, esto te puede dar un error parecido.
- max_input_vars: en formularios con miles de campos, se queda corto y da errores raros.
Todo esto se toca en el mismo php.ini, así que aprovecha el viaje. Reinicia Apache después y verifica con phpinfo() que los valores se han aplicado.
Cómo comprobar que el cambio ha funcionado
Crea un archivo info.php en tu carpeta htdocs con esto:
<?php phpinfo(); ?>
Ábrelo en el navegador como http://localhost/info.php y busca la fila max_execution_time. Si pone 300, todo correcto. Si sigue en 30, no has reiniciado Apache o estás editando otro php.ini. Este chequeo es la forma más rápida de cerrar el maximum execution time en XAMPP sin dudas.
Cuándo NO subir el límite
En producción, subir max_execution_time sin control es una mala idea. Un script que tarda 10 minutos bloquea un worker de PHP-FPM y puede tumbar el sitio. Si necesitas procesos largos, lo suyo es lanzarlos en segundo plano con cron, colas o workers. XAMPP es para desarrollar, ahí haz lo que quieras, pero no traslades esos valores a un servidor real.
Y si el error aparece en un WordPress local con XAMPP, mira primero los plugins. Muchas veces es uno que hace consultas pesadas y no hay php.ini que lo salve.