Loja virtual fora do ar: diagnóstico em 5 minutos
Quando a loja para de vender, cada minuto custa caro. Este guia te leva do "está fora do ar?" até a causa raiz em até 5 minutos, sem depender do suporte da hospedagem.
- Como confirmar em 30 segundos se a loja está fora do ar pra todo mundo ou só pra você.
- Tabela de diagnóstico por código HTTP (502, 503, 504, 500, NET::ERR_CERT_DATE_INVALID).
- Roteiro por camadas (DNS → SSL → web server → banco → integrações) — resolve ~90% dos casos sem SSH.
- Como rodar um pós-mortem útil em 15 minutos sem template formal.
Quando uma loja virtual para de vender, cada minuto custa caro. O custo médio de uma hora de downtime em e-commerce de médio porte fica entre R$ 5 mil e R$ 50 mil — só em vendas perdidas, sem contar tráfego pago jogado fora, churn e o impacto no ranking orgânico.[1]
O instinto na hora do aperto é ligar para o suporte da hospedagem e esperar. O problema: em metade dos casos, a hospedagem não é a culpada — e o suporte vai demorar 30 minutos só para confirmar isso.
Este guia é um roteiro objetivo para descobrir o que está quebrado em até 5 minutos, do seu computador, sem depender de ninguém. Funciona para qualquer loja — Magento 2, WooCommerce, Shopify, VTEX, Nuvemshop ou plataforma própria.
Passo 1 — Confirme que o problema não é só seu
Cinco em cada dez "incidentes" reportados pela equipe são, na verdade, problemas locais — não da loja.
Cache do navegador, DNS antigo do provedor de internet, VPN bloqueando, extensão quebrando o JavaScript. Antes de tocar em qualquer coisa do servidor, descarte essas possibilidades:
- Abra a loja em uma aba anônima e em outro dispositivo (use a rede 4G/5G do celular, fora do Wi-Fi do escritório).
- Use um verificador independente: verificador de site online faz a requisição a partir do nosso servidor — se ele diz que está no ar, o problema é seu; se também diz fora, o problema é da loja mesmo.
A regra de ouro do diagnóstico de incidente é: nunca confie em um único ponto de observação. Um ping vindo da mesma rede mente; três pings vindos de provedores diferentes não.
Mike Julian, em Practical Monitoring (O'Reilly, 2017)
Passo 2 — Identifique o tipo de erro
O código de status HTTP que aparece no browser (ou na resposta do verificador) já elimina metade das hipóteses. Os padrões mais comuns:
| Sintoma | Causa provável | Primeira ação |
|---|---|---|
| DNS não resolve / "servidor não encontrado" | Domínio expirou ou DNS apontando errado | Consulte verificador de DNS e o painel do seu registrar |
| Conexão estabelece mas página em branco | JavaScript quebrado no front-end | Abra o console do navegador (F12 → Console) |
HTTP 500 | Erro interno do servidor (PHP, framework, banco) | Ver logs da aplicação |
HTTP 502 (Bad Gateway) | Proxy/CDN não consegue falar com o backend | Verifique se PHP-FPM/Node/Apache está rodando |
HTTP 503 (Service Unavailable) | Servidor sobrecarregado ou em manutenção | Logs de CPU/memória e workers ativos |
HTTP 504 (Gateway Timeout) | Backend demorou demais para responder | Banco travado, integração lenta ou DDoS |
NET::ERR_CERT_DATE_INVALID | SSL expirou ou foi mal configurado | Renovar/instalar certificado (Let's Encrypt, painel) |
Passo 3 — Camadas, da mais externa para a mais interna
Investigue em ordem de probabilidade, do "lado fora" para o "lado dentro". Resolve 90% dos casos sem ter que abrir SSH no servidor.
3.1 — DNS e domínio
- Domínio expirou? Confira a data de validade no Registro.br ou no seu registrar.
- O DNS aponta para o IP certo? Use o verificador de DNS e compare o A record com o IP do seu servidor.
- Cloudflare/Akamai no meio? Veja se o "proxy laranja" está ativo e se a regra de cache está correta — uma page rule mal configurada pode entregar 522 para todo mundo.
3.2 — Certificado SSL
Certificado expirado quebra HTTPS de uma vez só — comum em quem usa Let's Encrypt sem renovação automática. O navegador exibe um aviso enorme, e nenhum cliente passa por ele. Diagnostique no inspetor de cabeçalhos HTTP.
3.3 — Infraestrutura (web server / aplicação)
- 502/504: 90% das vezes é PHP-FPM, Node ou Apache parado ou travado. Em Magento 2, verifique também se o Varnish está respondendo.
- 500: erro de aplicação. Veja
var/log/exception.log(Magento),wp-content/debug.log(WordPress/WooCommerce) ou o log do framework. - 503: servidor saturado. Cheque CPU e memória — pico de tráfego, job de cron pesado ou crawler de busca agressivo.
3.4 — Banco de dados
Banco lento é o gargalo mais comum em loja virtual de médio porte. O HTTP Archive (Web Almanac 2024) aponta que ~40% dos sites de e-commerce com TTFB acima de 1,5s têm o gargalo no banco, não na aplicação.[4] Se o backend está vivo mas as páginas dinâmicas (login, carrinho, checkout) não respondem, normalmente é MySQL/MariaDB sobrecarregado. Comandos úteis (precisa de SSH):
SHOW PROCESSLIST; # queries em execução
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Slow_queries';
SHOW ENGINE INNODB STATUS\G # locks, deadlocks, transações pendentesEm RDS/Amazon Aurora, olhe Performance Insights e CPU Utilization. Pico de "Threads connected" sem alta proporcional de tráfego = query travada segurando lock.
3.5 — Integrações externas
Se a loja abre mas o cliente não consegue concluir a compra, normalmente é integração externa em silêncio: gateway de pagamento, antifraude, transportadora, ERP, marketplace. Veja como detectar pedidos travados no Magento 2 — mesma lógica vale para WooCommerce e plataformas próprias.
Passo 4 — Pós-incidente: por que aconteceu?
Loja que cai e "volta sozinha" volta a cair. Sem entender a causa raiz, você está só rezando para o próximo pico não ser maior. O Google SRE Book chama isso de blameless postmortem — sem culpado, com foco em sistemas.[5]
O mínimo é responder, em até 24h:
- O que aconteceu? Sintoma, código de status, duração total, impacto em conversão.
- Por quê? Causa raiz, não causa imediata — "PHP-FPM caiu" é a causa imediata; "consumer do queue acumulou 50 mil mensagens" é a raiz.
- Como evitar? Alerta novo, limite ajustado, código corrigido, processo mudado.
Esse mini-post-mortem leva 15 minutos e evita o mesmo incidente em três meses. Não precisa de template formal — bastam três bullets num documento compartilhado.
Como evitar descobrir pelo cliente
Toda loja virtual deveria ter, no mínimo, monitoramento de uptime da home, do checkout e do certificado SSL. A regra é simples: você precisa saber do problema antes do cliente reclamar. Veja a lista mínima de 7 alertas que toda loja deveria ter.
Referências
- ITIC (Information Technology Intelligence Consulting). Hourly Cost of Downtime Survey, 2024. itic-corp.com · Gartner. The Cost of Downtime.
- IETF. RFC 9110 — HTTP Semantics, Section 15.6 (Server Error 5xx). datatracker.ietf.org/doc/html/rfc9110
- LinkedIn down after engineers forget to renew SSL certificate. The Register, dezembro 2017.
- HTTP Archive. Web Almanac — E-commerce chapter, 2024. almanac.httparchive.org/en/2024/ecommerce
- Beyer, Jones, Petoff & Murphy (orgs.). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly, 2016 — cap. 15 (Postmortem Culture).
- Akamai. The State of Online Retail Performance, 2017 e atualizações anuais. akamai.com
Perguntas frequentes
- Meu site não abre só pra mim ou para todo mundo?
- Use um verificador independente (de outro IP/rede) para confirmar. Se só você não acessa, normalmente é cache DNS, VPN ou conexão local. Se todo mundo está fora, o problema é na infraestrutura.
- O que significa erro 502 / 503 / 504?
- 502 (Bad Gateway) é o servidor web intermediário não conseguindo falar com o backend. 503 (Service Unavailable) é serviço indisponível, geralmente por sobrecarga. 504 (Gateway Timeout) é o backend que demorou demais para responder.
- Em quanto tempo um monitoramento detecta loja fora do ar?
- Depende da frequência. Monitoramentos baseados em ping detectam em segundos mas dão muito falso positivo; monitoramentos com navegação real (Chromium) detectam em 1–4 minutos com altíssima precisão.
- Se a loja voltou sozinha, ainda preciso investigar?
- Sim. Loja que cai sozinha e volta sozinha quase sempre cai de novo — com pico de tráfego, integração travando ou job de cron consumindo recurso. Trate cada incidente, mesmo curto, como sintoma de um problema estrutural.
Continue lendo
Monitore tudo isso automaticamente
A Especialista Loja Virtual roda navegação real no seu site a cada poucos minutos, alerta no Discord, Slack ou e-mail e mostra screenshot do incidente. Comece grátis.