Site fora do ar: o que fazer nos primeiros minutos, lendo a tela de erro

A tela que o cliente está vendo já diz em que ponto o pedido parou — e nos primeiros minutos vale mais salvar o log, reiniciar o serviço certo e desligar o que é opcional do que mexer na configuração no escuro.

Site fora do ar: o que fazer nos primeiros minutos

Com o site fora do ar, o que fazer nos primeiros minutos começa por ler a tela de erro que o cliente está vendo: ela diz em que ponto o pedido parou e qual recurso provavelmente acabou. Antes de apertar qualquer botão, a sequência é esta:

1. Confirme que a queda é geral: abra a loja em janela anônima e no celular com dados móveis, fora da sua rede.
2. Anote a tela exata e o horário: o código, a mensagem e o minuto em que você viu.
3. Veja se o servidor está vivo: painel do provedor ou acesso SSH, antes de qualquer reinício.
4. Salve o trecho de log do minuto da queda — é o que some assim que o serviço reinicia.
5. Só então aja, e sobre o serviço certo, não sobre a máquina inteira.

A ordem é essa por um motivo prático: reiniciar antes de anotar apaga a evidência. Você volta ao ar sem saber por quê — e, sem saber, repete no próximo pico.

Erro 5xx é resposta do servidor: o problema está do seu lado. Erro 4xx é resposta sobre o pedido do visitante (endereço que não existe, acesso negado, excesso de requisições no caso do 429). Nos primeiros minutos, é o 5xx que interessa.

Isto não substitui o suporte do seu provedor nem o diagnóstico feito com calma depois. É o que cabe na janela de minutos. E a expectativa honesta: a ação certa pode devolver o site ao ar rápido, mas se a máquina não tem capacidade sobrando o alívio dura pouco — e isso é assunto de outro dia, não da queda.

Erro 502, 503 e 504: a tradução de cada tela e o recurso que acabou

O código diz onde o pedido parou, não a causa raiz. 502 e 504 no mesmo minuto normalmente não são dois problemas: são o mesmo incidente visto em dois instantes, com processo morrendo de um lado e pedido esperando do outro.

Vale separar uma confusão comum: fila cheia de PHP-FPM costuma aparecer como 502 ou 504, porque o pedido chega a ser encaminhado e morre esperando. O 503 é mais frequentemente o servidor da frente dizendo que não há para onde encaminhar.

O tamanho da fila e o número de processos ocupados do PHP-FPM — definidos na configuração do serviço — são as métricas que enchem antes da queda. Se já estivessem sendo coletadas, você teria visto a rampa: é do que trata o monitoramento de VPS.

Banco de dados, página em branco e site lento mas no ar: as outras telas

Erro de conexão com o banco de dados (a mensagem clássica do WordPress e do WooCommerce): o banco recusou a conexão. Ou o serviço caiu, ou o limite de conexões simultâneas estourou, ou o disco encheu e ele parou de gravar. Verifique nessa ordem: serviço de banco de pé, conexões abertas, espaço em disco.

Página em branco: a aplicação executou e morreu no meio, normalmente por limite de memória do processo ou erro fatal do código depois de uma atualização. Às vezes vem acompanhada de um 500 Internal Server Error. Primeira verificação: o error log da aplicação, onde o erro fatal aparece com arquivo e linha.

Site lento mas no ar: nenhuma tela de erro, o cliente só desiste. É o estado anterior à queda — fila crescendo, tempo de resposta subindo — e a janela em que ainda dá para agir antes do prejuízo aparecer. O roteiro com calma está em como achar o gargalo na sua VPS.

Disco cheio merece parágrafo próprio: log que cresceu, backup que ninguém apagou, sessão acumulada. Costuma encher durante backup e rotina agendada, e o sintoma aparece disfarçado de qualquer uma das telas acima.

Por que a loja abre para mim e não abre para o cliente

É uma pergunta que atrasa o diagnóstico, porque faz o dono achar que está tudo bem. As explicações comuns:

• Você está logado e recebe uma página gerada por caminho diferente do visitante anônimo.
• Seu navegador ou o cache do provedor entrega uma versão guardada, sem tocar na aplicação.
• Seu IP já tem conexão aberta, enquanto o visitante novo pega a fila cheia.
• DNS ou CDN respondendo de forma diferente por região.

Carrinho e checkout são o termômetro porque não podem ser servidos de cache compartilhado: cada visita ali executa aplicação e banco. Se a home abre e o carrinho não, a loja está fora do ar para quem compra.

O inverso também vale: se a página abre de fora e não abre para você, o problema pode ser a sua rede ou um bloqueio por excesso de tentativas, não o servidor.

Antes de reiniciar: o que salvar para não repetir a queda

Reiniciar limpa estado — fila, conexões, processos em memória — e boa parte da evidência só existe enquanto o problema está acontecendo. Na ordem, copie:

1. Últimas linhas do error log da aplicação e do servidor web.
2. Trecho do access log no minuto da queda, que mostra qual URL recebeu a carga.
3. Mensagens do sistema sobre processo encerrado por falta de memória.
4. Uso de CPU, memória, swap e disco no horário.
5. Consultas longas no banco, se der para olhar antes de reiniciar.

Copie para fora da máquina — outra pasta, seu computador, uma nota. Se o problema for disco cheio, log é a primeira coisa que alguém apaga. Anote também o contexto humano: o que foi publicado ou alterado nas últimas horas, se havia campanha no ar ou alguma data de pico do e-commerce no calendário, se era horário de backup.

No dia seguinte, esse material é o que diferencia “faltou máquina” de “faltou configuração” — e as duas conclusões levam a caminhos opostos. Para descobrir o teto com calma, depois que a poeira baixar, veja quantos acessos simultâneos sua VPS aguenta.

A ação que cabe na janela de minutos: reiniciar o serviço certo, não a máquina

Regra de ouro: reiniciar a máquina inteira é a ação mais lenta e a que mais apaga evidência. Reiniciar só o serviço que travou restabelece o atendimento sem derrubar o resto. O código escolhe o serviço: 502 e 503 apontam para o processo da aplicação; erro de conexão com o banco aponta para o serviço de banco; se nem o servidor web responde, aí sim é a camada da frente.

1. Desligue o que é opcional enquanto a pressão passa: tarefa agendada pesada, importação de produto, sincronização com ERP, relatório, busca interna, recomendação de produto, chat. Cada função desligada devolve processo para atender quem está comprando.
2. Amplie o tempo de vida do cache de página, para servir mais visitante anônimo de página pronta. Efeito imediato e reversível — anote o valor antigo antes de mudar, e não estenda cache a carrinho, checkout e área do cliente.
3. Suba uma página de aviso se nada disso resolver. Uma página estática dizendo que a loja volta em instantes é melhor que um 502 cru: tira carga da aplicação e preserva a confiança do cliente. É ação legítima, não derrota.

Registre tudo em uma nota só, com horário: o que foi mudado, quando e por quem.

O que absolutamente não fazer sob pressão

• Trocar de plano ou migrar servidor no meio do pico. Migração tem janela de propagação e risco de dado desencontrado: você troca uma queda de minutos por uma de horas, e ainda decide capacidade no susto.
• Reinstalar, atualizar ou apagar plugin e tema para ver se melhora. Sem saber a causa, isso adiciona variável ao incidente — e atualização que mexe em tabela do banco não se desfaz com um clique.
• Mexer em configuração sem registrar o que mudou. Em meia hora ninguém lembra qual valor estava lá antes, e o rollback vira arqueologia.
• Rodar comando copiado de fórum sem entender. Comando de limpeza destrutivo executado com pressa é a forma mais rápida de transformar queda em perda de dado.
• Reiniciar repetidamente esperando outro resultado. Se voltou e caiu de novo em minutos, a causa continua lá — e cada reinício apaga mais evidência.
• Apagar log para liberar disco antes de copiar o trecho relevante: alívio real de espaço, evidência perdida junto.
• Prometer prazo ao cliente sem saber a causa.

Cloud bursting não é botão de emergência: onde o SwarmBurst entra e onde não entra

Sem rodeio: se a loja está fora do ar agora, o SwarmBurst não entra hoje. O agente precisa estar instalado e configurado no cluster antes do pico; não existe contratação no meio da queda.

Em uma frase: a loja segue na VPS fixa no dia normal e, quando a métrica passa do ponto que você definiu, sobem servidores extras por hora na nuvem pública, que entram no cluster e atendem junto; quando o movimento cai, esses nós saem e a cobrança deles termina ali. O conceito está em o que é cloud bursting.

O segundo recorte honesto: burst só ajuda quando a causa foi falta de capacidade. Queda por erro de configuração, plugin quebrado, consulta sem índice, disco cheio ou banco mal dimensionado não melhora com máquina extra — pode piorar, porque multiplica o erro.

Pré-requisito declarado: a loja precisa estar em contêineres dentro de um cluster. VPS com nginx, PHP e MySQL instalados direto no sistema tem um passo anterior de containerização, que é trabalho de verdade e entra no diagnóstico antes de qualquer proposta.

Roadmap, não entregue: hoje o agente sobe nó em AWS. GCP e Azure são roadmap e falham com erro explícito.

Se a queda já passou, o próximo passo é o preparo antes da data — como preparar a loja para a Black Friday sem trocar de servidor — e a decisão de capacidade tomada com calma, em servidor maior ou reforço só no pico, com a conta de manter tudo na nuvem o tempo inteiro comparada lado a lado.

Leve o log e o horário da queda para uma conversa no WhatsApp: quero entender se o meu caso é capacidade ou configuração. A gente decide com número medido, e diz na hora quando não é caso para nós.

Perguntas frequentes

Meu site saiu do ar agora: qual é a primeira coisa que eu faço?

A sequência dos primeiros minutos é: confirme que a queda é geral abrindo a loja em janela anônima e no celular com dados móveis; anote a tela exata, o código e o horário; verifique se o servidor está vivo no painel do provedor ou via SSH; salve o trecho de log do minuto da queda; só então aja sobre o serviço certo.

Reiniciar antes de anotar apaga a evidência — você volta ao ar sem saber por quê, e sem saber, repete no próximo pico.

O que significa erro 502, 503 e 504?

Erro 502 (Bad Gateway) significa que o servidor web encaminhou o pedido mas não recebeu resposta válida da aplicação — normalmente porque o processo morreu ou foi encerrado por falta de memória.

Erro 503 (Service Unavailable) significa que o servidor web respondeu sozinho dizendo que não tem a quem entregar o pedido — o serviço está parado, modo de manutenção ativo ou limite de requisições foi atingido.

Erro 504 (Gateway Timeout) significa que a aplicação não respondeu dentro do tempo limite — causa típica é consulta de banco travada, integração externa lenta ou disco saturado.

Devo reiniciar o servidor inteiro ou dá para reiniciar só um serviço?

Reiniciar a máquina inteira é a ação mais lenta e apaga mais evidência. O melhor é reiniciar só o serviço que travou: 502 e 503 apontam para o processo da aplicação; erro de conexão com banco aponta para o serviço de banco; se nem o servidor web responde, aí sim é a camada da frente.

Antes de reiniciar, desligue o que é opcional — tarefa agendada pesada, importação, sincronização com ERP, relatório, busca, recomendação, chat — para devolver processo disponível para quem está comprando.

Por que o site abre para mim e não abre para os meus clientes?

A razão mais comum é que você está logado e recebe página gerada por caminho diferente do visitante anônimo. Outras razões: seu navegador ou cache do provedor entrega versão guardada; seu IP já tem conexão aberta enquanto visitante novo pega fila cheia; DNS ou CDN respondem de forma diferente por região.

O termômetro é carrinho e checkout — que não podem ser servidos de cache compartilhado — porque ali a execução é sempre fresca. Se a home abre e o carrinho não, a loja está de fato fora do ar para quem compra.

O que eu preciso salvar antes de reiniciar para descobrir a causa depois?

Copie para fora da máquina, nesta ordem: últimas linhas do error log da aplicação e do servidor web; trecho do access log no minuto da queda; mensagens do sistema sobre processo encerrado por falta de memória; uso de CPU, memória, swap e disco no horário; consultas longas no banco, se der para olhar.

Anote também o contexto: o que foi publicado ou alterado nas últimas horas, se havia campanha no ar ou data de pico de vendas, se era horário de backup. Esse material é o que diferencia ‘faltou máquina’ de ‘faltou configuração’.