~/blog · 12 de agosto de 2026
Anatomía de un error 500: la caída de un sitio en plena temporada de matrículas
Un miércoles de agosto, en plena temporada de matrículas, el sitio de una red de escuelas de música en Medellín empezó a mostrar la pantalla más temida del internet institucional: error 500. A veces cargaba. A veces no. El panel de administración fallaba justo cuando el equipo intentaba revisar las inscripciones de los niños.
Este es el postmortem real de ese incidente: qué falló, cómo se diagnosticó y qué aprendimos. Lo publico porque el patrón se repite en cientos de organizaciones — fundaciones, colegios, pymes — y porque las señales eran visibles desde meses antes.
El síntoma: intermitente, que es lo peor
Un sitio caído del todo es fácil de tomar en serio. Uno que falla a veces genera meses de “recarga la página y vuelve a intentar”. Aquí los números del primer día de diagnóstico:
- 300+ errores 500 registrados en 24 horas
- Fallos en la página principal, el módulo de matrículas, la intranet y el panel administrativo
- Tiempos de respuesta de 2 a 6 segundos antes de cada fallo
Ese último dato importa: no eran timeouts. Algo consumía toda la memoria del servidor en segundos.
El diagnóstico: los logs no mienten
Por SSH, la primera parada fueron los registros del servidor. El log de errores de PHP contenía la respuesta literal:
PHP Fatal error: Allowed memory size of 536870912 bytes
exhausted (tried to allocate 262144 bytes)536.870.912 bytes = 512 MB de memoria agotados por una sola visita. Para dimensionarlo: una página de WordPress sana consume entre 40 y 80 MB. Este sitio tenía disponible un límite 6 veces mayor que lo normal — y aún así lo reventaba. Solo el primer día del incidente hubo 585 errores fatales de memoria.
La pregunta correcta no era “¿cómo le damos más memoria?”, sino “¿qué se está comiendo 512 MB por visita?”.
La causa raíz nunca es una sola
Excavando en los registros de depuración apareció la arqueología completa del problema:
1. Componentes de 2020 corriendo en 2026. Tres plugins críticos llevaban seis años sin actualizarse porque su licencia comercial había vencido en 2021. Sin licencia, no hay actualizaciones; sin actualizaciones, no hay compatibilidad con las versiones modernas de PHP.
2. 1.3 millones de avisos de código obsoleto por día. Esos plugins viejos, corriendo sobre PHP 8.3, generaban tal cantidad de avisos que el archivo de registro crecía 364 MB diarios. El sitio acumulaba casi un gigabyte de logs de sus propios gritos de auxilio.
3. Modo de depuración activo en producción. La configuración tenía WP_DEBUG encendido (con un error de sintaxis adicional: 'true' como texto en vez de booleano). Cada aviso se escribía a disco, en cada visita.
4. Una tabla de base de datos de 520 MB solo de logs de correos. El plugin de correo guardaba una copia de cada email enviado… con retención de 365 días.
5. Tareas pesadas ejecutándose dentro de las visitas. Sin un cron de sistema configurado, WordPress ejecutaba los envíos de correo masivo, la regeneración de caché y los escaneos de seguridad dentro de las peticiones de los visitantes. La visita que tenía la mala suerte de disparar la tarea pesada, moría con un 500.
Ninguno de estos problemas tumba un sitio por sí solo. Los cinco juntos, sí.
Las primeras 48 horas
El orden importa: primero estabilizar, después modernizar.
Día 1 — parar el sangrado: corrección de la configuración de depuración, archivado de ~1.4 GB de logs, retención de correos reducida de 365 a 14 días (la tabla pasó de 520 MB a 22 MB, con respaldo previo), y diagnóstico de memoria por componente para identificar a los responsables exactos.
Día 2 — atacar la causa: actualización de los componentes críticos desactualizados, realineación de versiones incompatibles entre plugins hermanos, y configuración de un cron de sistema real para que las tareas pesadas dejaran de correr dentro de las visitas.
Todo por SSH, sin apagar el sitio, con respaldo antes de cada cambio y verificación después de cada paso.
Los resultados
| Métrica | Antes | Después |
|---|---|---|
| Errores 500 diarios | 300+ | 0 |
| Memoria por visita | ~200 MB | 32-40 MB |
| Avisos en logs por día | 1.3 millones | ~0 |
| Tabla de logs de correo | 520 MB | 22 MB |
| Registros protegidos | — | 113.000+ matrículas y asistencias |
Cero caídas desde la intervención. Y más importante: la organización ahora tiene un plan de modernización por fases, porque estabilizar no es lo mismo que resolver — el sitio sigue siendo una acumulación de plugins que algún día debe simplificarse.
Las 6 señales de que tu sitio va por el mismo camino
- Nadie recuerda cuándo se actualizó algo por última vez. Si la respuesta es “hace años”, tienes deuda técnica acumulando interés.
- Hay licencias comerciales vencidas. Un plugin de pago sin licencia es un plugin congelado en el tiempo — sin parches de seguridad.
- El sitio “a veces falla” y todos lo aceptan. La intermitencia es la fase previa al colapso, no un estado estable.
- Tu operación crítica vive en formularios y plugins. Matrículas, inventarios, pagos: si eso corre sobre el mismo WordPress que el blog, un plugin roto detiene tu operación.
- Nadie revisa los logs. Este sitio llevaba meses documentando su propia enfermedad, 1.3 millones de líneas por día. Nadie los leía.
- No hay contrato de mantenimiento. Las emergencias siempre cuestan más que la prevención — en dinero y en confianza de tus usuarios.
La moraleja
Este incidente no fue causado por un ataque, ni por el hosting, ni por mala suerte. Fue mantenimiento diferido: años de “después lo vemos” cobrándose en la peor semana posible, la de matrículas.
La tecnología aburrida —actualizada, monitoreada, con respaldos verificados— es la que no se cae.
¿Tu plataforma muestra alguna de las 6 señales? Escríbeme a felipe@tause.pro o por WhatsApp y te doy un diagnóstico honesto — incluso si la respuesta es “no me necesitas”.