O site inteiro devolve 503 com “Momentaneamente indisponível para manutenção programada. Confira novamente em um minuto” e o minuto virou meia hora. Isso é um arquivo, não um bug: a atualização de plugin ou de core morreu no meio e deixou o .maintenance na raiz do WordPress. Apagou, o site volta na hora.
Por SSH, na pasta onde ficam o wp-config.php e a wp-includes:
cd /var/www/seusite/html
ls -la .maintenance
rm .maintenance
sudo -u www-data wp maintenance-mode statusSe preferir não apagar na mão, wp maintenance-mode deactivate remove o mesmo arquivo. Por FTP é igual, com um detalhe: o nome começa com ponto, então ligue a exibição de arquivos ocultos no FileZilla, senão você jura que ele não existe.
Por que ele não sumiu sozinho
O arquivo tem uma linha só, com a variável $upgrading e o timestamp de quando a atualização começou. A wp_is_maintenance_mode(), na wp-includes/load.php, ignora esse arquivo assim que o carimbo passa de dez minutos. Se a tela insiste depois disso, ou o timestamp está no futuro (relógio do servidor fora de hora) ou alguma rotina recria o arquivo a cada tentativa. Se a página for personalizada, quem manda é o wp-content/maintenance.php, não o core.
Termine o que ficou pela metade
Apagar o arquivo tira a tela, mas não garante que o update foi até o fim. Core cortado no meio deixa arquivo novo com banco velho, e aí sobra erro no admin. Com backup do banco feito, feche o ciclo:
sudo -u www-data wp core version
sudo -u www-data wp core update
sudo -u www-data wp core update-db
sudo -u www-data wp plugin list --update=availableRodar a atualização pelo WP-CLI em vez do painel tira o timeout de navegador da jogada, que é justamente o que derruba o processo na maioria das vezes.
Antes de sair, olhe wp-content/upgrade e wp-content/upgrade-temp-backup. As duas vivem entulhadas de resto de atualização abortada e podem ser esvaziadas com o site no ar — só não faça isso com um update rodando, porque a segunda guarda o backup que o WordPress usa pra desfazer a instalação.