Qual a causa mais comum de um sistema sair do ar?

As três campeãs em sistemas pequenos e médios são disco cheio, certificado SSL vencido e o processo da aplicação derrubado por falta de memória. Todas são baratas de prevenir e caras de descobrir na correria. Um monitoramento simples avisa das três antes do usuário perceber.

Como saber se o problema é meu ou do provedor?

Teste o acesso de uma rede diferente, por exemplo pelo 4G do celular, e verifique a página de status do provedor de hospedagem. Se o site responde de fora e não de dentro da empresa, o problema é a rede local ou o DNS interno. Se não responde de lugar nenhum, é servidor ou aplicação.

Quanto tempo é aceitável esperar por uma resposta durante uma queda?

Isso deveria estar escrito no contrato, não ser descoberto durante o incidente. Um acordo comum em sistemas de operação diária é primeira resposta em até uma hora no horário comercial e canal de plantão para fora dele. Sem contato nomeado e canal definido, qualquer prazo é promessa verbal.

Meu sistema caiu e ninguém resolve: o plano de ação

Faça na ordem, sem pular etapa. Nas primeiras duas horas você tem duas tarefas paralelas: diagnosticar a causa e colocar a operação num contorno manual. A segunda é mais importante que a primeira, porque nota fiscal, entrega e atendimento não podem esperar o diagnóstico terminar.

Os primeiros 15 minutos: isole onde está o problema

Antes de acusar qualquer fornecedor, responda estas perguntas em sequência. Cada uma elimina uma camada.

O sistema responde de outra rede? Abra pelo 4G do celular, fora do Wi-Fi da empresa. Se funciona, o problema é a rede local, o DNS interno ou um bloqueio de firewall da empresa.
O navegador mostra qual erro? "Não foi possível encontrar o servidor" aponta para DNS. "Sua conexão não é particular" aponta para certificado. "502" ou "503" significa que o servidor está de pé, mas a aplicação por trás não. "500" significa erro dentro da aplicação.
O domínio ainda está ativo? Verifique a data de vencimento no registrador. Domínio expirado derruba tudo de uma vez, inclusive e-mail.
A hospedagem tem incidente aberto? Toda provedora séria mantém uma página de status pública.
Alguma coisa mudou nas últimas 24 horas? Publicação, atualização, mudança de senha, integração nova. Em sistemas estáveis, quedas raramente são espontâneas.

Escreva o horário de cada verificação. Essa linha do tempo vira a evidência que você vai usar na conversa seguinte com o fornecedor.

Sintoma, causa provável e quem resolve

Sintoma	Causa mais provável	Quem resolve
Erro de segurança no navegador, cadeado quebrado	Certificado SSL vencido ou renovação automática falhou	Quem administra o servidor, em minutos
"Servidor não encontrado" para todos	DNS alterado, domínio expirado ou zona removida	Quem controla o registrador e o DNS
Página em branco ou erro 500	Falha na aplicação após uma publicação	Desenvolvedor, com reversão para a versão anterior
Erro 502 ou 503 intermitente	Processo da aplicação caiu por falta de memória	Administrador do servidor, com reinício e depois ajuste de limite
Sistema lento e depois trava	Disco cheio, quase sempre por log ou backup acumulado	Administrador do servidor, liberando espaço e criando rotina de limpeza
Login funciona, mas nada salva	Banco de dados sem espaço, travado ou com conexões esgotadas	Quem administra o banco
Só uma função quebrou	Integração de terceiro fora do ar ou credencial expirada	Desenvolvedor, verificando o serviço externo
Lento só na empresa, rápido fora	Rede local, proxy ou link de internet	Suporte de TI local ou provedor de internet

A coluna mais útil é a terceira. Boa parte do tempo perdido numa queda não é técnico: é descobrir quem é responsável por qual camada. Ter isso mapeado antes da crise reduz horas de parada.

Como montar um contorno manual em 30 minutos

Sistema fora do ar não pode significar operação parada. Para a maioria das empresas, um contorno provisório é montável rápido.

Vendas e pedidos: planilha compartilhada com as mesmas colunas do cadastro do sistema, preenchida por quem atende
Atendimento: aviso curto e honesto no WhatsApp e nas redes, com previsão realista e canal alternativo
Emissão fiscal: emissor gratuito da própria Sefaz ou o portal do contador, se a emissão passa pelo sistema
Estoque e expedição: registro em papel com conferência dupla, digitado depois
Financeiro: extrato bancário direto, com conciliação posterior

Duas regras que evitam dor de cabeça depois: registre tudo com data e hora, e nomeie uma única pessoa responsável por digitar esse acúmulo no sistema quando ele voltar. Contorno sem responsável de digitação vira divergência de estoque três semanas depois.

Que evidência registrar durante a queda

Isso não é burocracia, é o que permite exigir mudança depois.

Horário exato em que o problema começou e como foi percebido
Prints das mensagens de erro, com o endereço visível na barra
Horário de cada tentativa de contato e por qual canal
Horário de cada resposta recebida, com o teor
Duração total da indisponibilidade
Impacto estimado: pedidos não processados, atendimentos perdidos, horas de equipe parada

Suponha uma operação que fatura em torno de R$ 30 mil por dia útil. Seis horas fora do ar equivalem, em ordem de grandeza, a algo perto de R$ 22 mil de faturamento deslocado ou perdido, sem contar retrabalho. Colocar esse número na conversa muda completamente o tom da negociação sobre monitoramento e plantão.

O que exigir depois que voltar ao ar

Sistema no ar de novo é o pior momento para relaxar e o melhor para negociar. Peça estes cinco itens por escrito.

Item	O que é aceitável	O que não é
Monitoramento	Verificação automática a cada poucos minutos, com alerta por e-mail ou WhatsApp	"A gente olha de vez em quando"
Backup	Automático, diário, guardado fora do servidor principal	Backup no mesmo servidor que caiu
Teste de restauração	Restauração real feita em ambiente separado, com data registrada	"Existe backup" sem nunca ter sido restaurado
Contato de plantão	Nome, telefone e canal, com horário de cobertura definido	Só e-mail de suporte genérico
Relatório do incidente	Uma página: o que houve, por que, o que foi feito, o que impede repetir	Explicação verbal por telefone

O item que mais gente ignora é o terceiro. Backup que nunca foi restaurado não é backup, é arquivo. É comum descobrir, no pior dia possível, que a rotina rodava há meses gravando um arquivo vazio ou incompleto. Exija uma restauração de teste com data e resultado documentado, pelo menos a cada trimestre.

O que colocar no contrato para não repetir

Três cláusulas resolvem a maior parte dos casos:

Tempo de resposta, não de solução. Solução depende da causa e não dá para prometer. Resposta depende só de organização. Defina prazo de primeira resposta por gravidade: sistema totalmente parado, função crítica indisponível, problema pontual.

Acesso de emergência. Você precisa ter credencial administrativa do servidor, do banco e do registrador, guardada em cofre de senhas da empresa. Se depender de uma única pessoa atender o telefone, você não tem plano de contingência, tem sorte.

Runbook de uma página. Um documento simples listando: onde o sistema está hospedado, como reiniciar a aplicação, onde ficam os backups, como restaurar, e quem chamar em cada camada. Qualquer profissional competente consegue agir com esse documento, mesmo sem conhecer o projeto.

Sistemas caem. Isso é normal e acontece com todo mundo. O que separa uma queda de duas horas de uma queda de dois dias não é a qualidade do código: é ter monitoramento que avisa antes do cliente, backup que restaura de verdade e alguém nomeado para atender. Esses três itens custam pouco e são a diferença entre um incidente e uma crise.