Logo
WP Fix by Blimx

WordPress Atascado en Modo Mantenimiento — Procedimientos de Escape

Actualizado:
ErrorsRecovery

Qué significa el mensaje

Cuando WordPress empieza una actualización de core, plugin o tema, crea un archivo llamado .maintenance en la raíz del sitio. Mientras ese archivo exista, cada petición obtiene el mensaje:

Briefly unavailable for scheduled maintenance. Check back in a minute.

Cuando la actualización se completa exitosamente, WordPress borra .maintenance. El sitio vuelve a la normalidad.

El problema: si la actualización falla a mitad — error de memoria, timeout de PHP, caída de red — WordPress nunca llega al paso de borrado. El archivo .maintenance se queda. Tu sitio se queda en modo mantenimiento indefinidamente.

Este artículo es el procedimiento de escape para cada variación que hemos visto.

Método 1 — Borrar el archivo .maintenance vía FTP

El método más rápido, funciona para el 95% de los casos.

Pasos

  1. Conéctate vía SFTP/FTP a tu sitio
  2. Navega a la raíz de WordPress (donde vive wp-config.php)
  3. Encuentra un archivo llamado literalmente .maintenance
  4. Bórralo
  5. Refresca tu sitio

Eso es todo. El mensaje de mantenimiento desaparece.

Nota: Algunos clientes FTP ocultan dotfiles por defecto. En FileZilla: menú Servidor → Forzar mostrar archivos ocultos.

Método 2 — Borrar vía SSH

Si tienes acceso SSH:

cd /var/www/yoursite
rm -f .maintenance

Listo. Refresca el sitio.

Método 3 — Borrar vía WP-CLI

cd /var/www/yoursite
wp maintenance-mode deactivate

WP-CLI maneja el borrado de forma segura y confirma.

Método 4 — Borrar vía gestor de archivos del hosting

Si no tienes SSH ni FTP:

  1. Entra al panel del hosting (cPanel, Plesk)
  2. Abre el Administrador de Archivos
  3. Habilita "Mostrar Archivos Ocultos" en el menú de configuración
  4. Navega a public_html/ o tu raíz WordPress
  5. Borra .maintenance

Método 5 — Restaurar desde backup si todo lo demás falla

En casos raros la actualización fallida hizo más daño que solo dejar .maintenance. El sitio post-borrado muestra errores, pantallas blancas o funcionalidad parcial. En este caso:

  1. Restaura la base de datos del último backup bueno
  2. Restaura archivos (especialmente wp-content/) desde backup
  3. Re-corre la actualización con límites de recursos apropiados

Esto es destructivo — cualquier dato creado durante la ventana de actualización fallida se pierde. Úsalo solo cuando otros métodos producen un sitio roto después de remover .maintenance.

Tras el borrado: verifica la integridad

Solo borrar .maintenance no garantiza un sitio funcional. La actualización interrumpida puede haber dejado archivos parciales. Corre estos checks:

1. Versión de WordPress

wp core version

Si la versión es la que esperabas (la versión objetivo de la actualización), la actualización del core se completó. Si es la versión vieja, la actualización del core nunca terminó — re-córrela.

2. Schema de base de datos

wp core update-db

Esto re-corre de forma segura cualquier migración de schema pendiente. No-op si todo está hecho.

3. Integridad de plugins

wp plugin list --status=active

Para cada plugin, verifica que la versión coincida con lo que pretendías. Algunos plugins pueden necesitar reinstalación:

wp plugin install <slug> --version=<X.Y.Z> --force

4. Integridad de archivos

wp core verify-checksums

Esto compara tus archivos del core contra los checksums publicados de WordPress. Cualquier archivo modificado o faltante se reporta.

¿Por qué falla una actualización en primer lugar?

Entender la causa previene recurrencia:

Causa A — Agotamiento de memoria PHP

El proceso de actualización carga archivos en memoria. Actualizaciones grandes (WooCommerce, Elementor, BuddyPress) necesitan 256MB+ para completar. El default de 128MB choca contra la pared.

Arreglo: Configura WP_MEMORY_LIMIT en wp-config.php a 512M.

Causa B — Timeout de ejecución de PHP

Actualizaciones largas exceden max_execution_time. El default es 30s; algunas actualizaciones necesitan 5 minutos.

Arreglo: En php.ini:

max_execution_time = 300

Causa C — Caída de red mientras descarga la actualización

WordPress busca el paquete de actualización de wp.org. Si la conexión saliente de tu servidor se cae a mitad de descarga, el archivo se corrompe.

Arreglo: Resolver DNS y ruta estables. Para servidores poco confiables, descarga manualmente y coloca el archivo de actualización.

Causa D — Permisos de archivos equivocados

WordPress escribe archivos durante la actualización. Si los permisos son demasiado restrictivos, la escritura falla a la mitad.

Arreglo: Asegura que directorios son 755, archivos 644, propiedad del usuario del servidor web.

Causa E — Disco lleno

Sin espacio en disco a mitad de actualización. La actualización escribe archivos parciales y luego muere.

Arreglo: Libera espacio en disco; asegura al menos 2GB libres antes de cualquier actualización.

Checklist de prevención

Una vez que te recuperaste, haz esto rutina para la próxima actualización:

  • [ ] Backup de base de datos (wp db export pre-update.sql)
  • [ ] Backup de wp-content/ (tar -czf wp-content-backup.tar.gz wp-content/)
  • [ ] Confirma 2GB+ de disco libre
  • [ ] Confirma memoria PHP ≥ 512MB
  • [ ] Confirma max_execution_time PHP ≥ 300
  • [ ] Actualiza en staging primero si el sitio es crítico de negocio
  • [ ] Actualiza durante horas de bajo tráfico
  • [ ] Mantén una sesión SSH/FTP abierta para rescatar rápido

Errores comunes tras un mantenimiento atascado

  • Reinstalar WordPress sobre el estado roto — puede dejar una mezcla de archivos viejos/nuevos
  • Editar manualmente `wp-config.php` "para arreglar la base de datos" — usualmente crea errores nuevos
  • Restaurar backup antes de identificar qué falló — pierde datos de clientes innecesariamente
  • Intentar la misma actualización de nuevo sin cambiar nada — la misma memoria/timeout que falló fallará de nuevo

Cuándo llamar a un especialista

Si has removido .maintenance pero el sitio está ahora roto de nuevas formas (pantalla blanca, errores de base de datos, admin faltante), la actualización hizo daño real. Recuperamos sitios así cada semana sin perder datos cuando hay backups, y minimizamos pérdida cuando no los hay.

Emergencia de modo mantenimiento en minutos. Para recuperación más amplia ve soporte de emergencia WordPress.