Eu criei o Gitae porque continuava encontrando a mesma pergunta prática: o site está realmente fora do ar ou o problema está só do meu lado?
Uma única aba do navegador é uma ferramenta de diagnóstico fraca. Uma página pode não carregar porque o origin server caiu, mas também por DNS, problema no certificado HTTPS, routing, regra de firewall, porta fechada ou filtrada, ISP, caminho da VPN, estado do navegador ou cache local. O sintoma visível é o mesmo. A ação correta, não.
Era isso que eu queria resolver no Gitae: não apenas mostrar um indicador verde ou vermelho, mas ajudar a reduzir o problema à camada que faz sentido investigar em seguida.
O problema real por trás de “o site caiu”
Muitos verificadores simples respondem uma pergunta estreita: essa URL respondeu de um lugar específico em um momento específico? Isso é útil, mas ainda não é diagnosticar uma indisponibilidade.
Se o DNS está errado, reiniciar a aplicação não resolve. Se HTTPS falha por causa do certificado, alterar o conteúdo da página é irrelevante. Se uma porta TCP não é alcançável, o servidor ainda pode estar funcionando. E se o site abre de um servidor externo, mas não da minha conexão, o problema pode estar em algum ponto entre a minha rede e o destino, e não no application server.
Por isso organizei o Gitae em torno de um modelo mais útil: um site é uma cadeia de dependências, e cada teste fornece evidência sobre apenas uma parte dessa cadeia.
Uma visão externa, não um oráculo
Os testes do Gitae rodam nos meus próprios servidores VDS em Moscou e Helsinque. Isso me dá pontos de observação fora do computador e da rede onde percebi o problema.
Se o site falha localmente, mas responde nos dois VDS, isso é um sinal útil de que o origin pelo menos não está inacessível para todo mundo. Nesse caso, eu olho com mais atenção para DNS local, rota do ISP, VPN, navegador, firewall ou outro problema dependente do caminho de rede. Se também falha nas sondas remotas, aumenta a razão para investigar servidor, DNS, certificado, routing ou um problema de rede mais amplo.
Mas um teste remoto não é automaticamente “mais confiável” que um teste local. Duas localizações VDS não representam toda a internet. Um site pode funcionar em Moscou e Helsinque e falhar em outro país, ISP, CDN edge ou rede. Eu trato o resultado remoto como um ponto de observação adicional, não como um veredito global.
O que o Gitae verifica hoje
- Website check — verifica se uma URL responde a partir de um servidor externo.
- SSL check — inspeciona o estado do certificado HTTPS/TLS e problemas relacionados ao certificado.
- DNS check, nslookup e dig — ajudam a ver como o domínio resolve e quais registros DNS são retornados.
- Reverse DNS e IP check — mostram informações de IP e dados PTR/reverse-DNS.
- Domain info e domain age — fornecem metadados básicos do domínio.
- Port check — testa se uma porta é alcançável a partir da localização da sonda.
- Find your IP — mostra o IP público visível para o serviço.
- Ping e traceroute — fornecem sinais de rede sobre latência, perda de pacotes e caminho até o host.
- Hosting check e CMS detection — mostram sinais de infraestrutura e tecnologia que podem ajudar na identificação.
Eu trato esses resultados deliberadamente como sinais. Um registro PTR não prova quem é dono do servidor. CMS detection baseada em fingerprints públicos não prova o stack exato. Uma porta inacessível a partir de uma sonda pode estar sendo filtrada no caminho, em vez de estar fechada para todos.
Como interpreto os resultados
O valor aparece quando vários testes são analisados em conjunto.
Se o DNS retorna o endereço esperado, o certificado HTTPS é válido e o site responde a partir dos dois VDS, mas eu ainda não consigo abrir localmente, eu investigaria primeiro o caminho local antes de alterar o servidor. Se o DNS está inconsistente ou o website check remoto também falha, há mais motivos para investigar a infraestrutura.
Ping e traceroute também exigem cautela. ICMP pode ser filtrado ou rate-limited. Um hop ausente no traceroute não significa automaticamente que aquele roteador está quebrado, e um host que não responde a ping pode servir HTTPS normalmente. Essas ferramentas adicionam contexto; não entregam um diagnóstico definitivo.
A regra principal para mim é: um único teste bem-sucedido não prova que todo o sistema está saudável, e um único teste com falha não explica sozinho a causa.
Disponibilidade e SEO não são a mesma coisa
Disponibilidade também importa para SEO, mas indisponibilidade técnica não é a mesma coisa que problema de ranking. Crawling não é indexing, e indexing não é traffic.
Se um crawler não consegue alcançar o site por erros de DNS, rede ou servidor, ele não consegue buscar corretamente o conteúdo afetado naquele momento. O Google documenta que erros de rede e DNS durante o crawling são tratados de forma semelhante a erros de servidor 5xx, e que indisponibilidade prolongada pode afetar o crawl e URLs já indexadas. Isso não significa que toda interrupção curta cause automaticamente perda de SEO, nem que uma ferramenta de diagnóstico possa provar que uma mudança posterior de tráfego foi causada por aquela queda.
Para usuários, a lógica é mais simples: se não conseguem acessar o site, não conseguem usá-lo. Dependendo do projeto, isso pode significar sessões, leads, conversões ou receita perdidos. O diagnóstico técnico, porém, não calcula esse impacto de negócio.
Uma ordem prática para investigar um site “fora do ar”
- Confirmar o sintoma em outra rede. Não assumir que o navegador local representa toda a internet.
- Verificar DNS. Confirmar resolução e registros esperados.
- Verificar HTTPS/TLS. Examinar certificado e erros de conexão.
- Verificar a porta necessária. Testar alcance a partir da sonda.
- Comparar sinais de rede. Usar ping e traceroute como suporte.
- Olhar IP, reverse DNS, hosting e CMS. Esses sinais ajudam a confirmar que você está chegando à infraestrutura esperada.
- Só então reduzir a investigação. Decidir se a evidência aponta mais para aplicação, servidor, DNS, caminho de rede ou ambiente local.
Isso não é um protocolo universal de incident response. É uma maneira de evitar o erro que eu queria eliminar: mudar a camada errada só porque a única informação inicial é “o site não abre”.
Primeiro utilidade real, depois monetização
O Gitae não é monetizado no momento. Eu o construí primeiro para mim porque queria uma forma rápida de verificar um site de fora da minha própria máquina e, em seguida, ir direto para DNS, certificado, portas e rede sem alternar entre ferramentas desconectadas.
Meu objetivo atual é tornar o diagnóstico mais útil e ver se o projeto pode atrair tráfego orgânico por SEO e demanda real. Se atingir mesmo um tráfego moderado, quero adicionar monitoramento automático de sites com alertas instantâneos em mensageiros. Seria a mesma ideia estendida do diagnóstico manual para a detecção: perceber que algo ficou indisponível e dar ao proprietário informação suficiente para começar a investigar rapidamente.
O princípio central continua simples
“Online” e “offline” são sintomas, não explicações.
DNS, HTTPS/TLS, routing, portas, hospedagem, aplicação e a própria rede do usuário podem produzir o mesmo problema aparente de disponibilidade. O Gitae não identifica magicamente toda root cause, e essas localizações VDS externas não mostram o que toda a internet enxerga. Mas ele pode reunir vários sinais independentes no mesmo lugar.
Era isso que eu queria para mim: passar de “o site não abre” para uma pergunta muito mais útil: “qual camada eu devo investigar agora?”