Verifique se um site ou servidor está no ar e veja o código de status HTTP real e o que significa, o tempo de resposta, a cadeia completa de redirecionamentos, o certificado SSL e o servidor por trás. Verifique um ou cole vários. Sem cadastro.
O verificador de status do servidor é uma ferramenta que envia uma requisição HTTP real para um endereço e informa se ele está no ar, qual código de status o servidor devolveu e quanto tempo levou para responder. A versão do ToolsPivot vai além do sim ou não: ela mostra a cadeia completa de redirecionamentos, o certificado SSL, o servidor e a CDN por trás do site e quais cabeçalhos de segurança estão presentes. Tudo roda no nosso servidor, com HTTP puro, sem cadastro e sem chave de API.
A ferramenta recebe uma URL (ou até vinte de uma vez), faz uma requisição HTTP real a partir do nosso servidor e devolve um diagnóstico completo da resposta. Ela captura o código de status e o significado dele em português claro, o tempo até o primeiro byte, o tempo total, cada salto de redirecionamento, os dados do certificado e os cabeçalhos que o servidor expõe. Você cola o endereço na aba "Uma URL", clica em "Verificar status" e o resultado aparece em poucos segundos. Funciona com ou sem o http(s) na frente.
Quem mais usa esse tipo de checagem são desenvolvedores validando um deploy, profissionais de SEO investigando por que uma página sumiu do índice e agências que administram dezenas de sites de clientes. Donos de loja no Mercado Livre ou em site próprio também recorrem à ferramenta quando o site parece fora do ar e ninguém sabe dizer se o problema é do servidor ou da conexão de quem está reclamando.
O navegador não consegue ler o código de status real de outro site. Por causa da política de mesma origem, uma requisição entre domínios diferentes volta como resposta opaca, com status 0 e sem nenhum cabeçalho, justamente para impedir que um site leia os dados de outro. Rodando do lado do servidor, sem essa restrição, a ferramenta enxerga a resposta inteira e entrega o código exato, os cabeçalhos e os tempos que o navegador esconderia de você.
Para um retrato mais amplo da saúde técnica do site, vale rodar a checagem junto com o verificador de SEO do site, que cobre pontos que o status HTTP sozinho não alcança.
Server e X-Powered-By revelam o software por trás da resposta quando não estão ocultos.CF-Ray para Cloudflare, x-vercel-id, X-Amz-Cf-Id para CloudFront, além de Varnish, Fastly e Akamai.A checagem vale mais nos momentos em que uma mudança acabou de acontecer e ninguém confirmou o efeito dela. É nesses intervalos que erros silenciosos se instalam e só aparecem dias depois, quando o tráfego já caiu.
Em casos de bloqueio regional a resposta é diferente. Como a checagem parte de um único ponto, ela confirma o estado do site a partir daqui, mas não substitui uma rede de sondas distribuídas.
Contexto: um lojista com anúncios no Mercado Livre e site próprio precisa entrar na Black Friday sem página quebrada.
Resultado: os erros são corrigidos antes de a campanha começar, e não durante o pico de visitas.
Contexto: uma agência administra dezenas de sites e precisa de rotina semanal de verificação sem contratar monitoramento pago para cada cliente.
Resultado: a agência descobre a queda antes do cliente, o que muda completamente o tom da conversa.
Contexto: um desenvolvedor moveu um site para novo servidor e precisa provar que os redirecionamentos antigos continuam funcionando.
Resultado: cadeias em loop e redirecionamentos apontando para o domínio antigo aparecem antes de virarem chamado de suporte.
Contexto: um analista recebe reclamação de site lento, mas o relatório de performance não aponta causa clara.
Resultado: a equipe descobre que a demora estava na espera do servidor, e não na rede. O teste de compressão GZIP e o verificador de velocidade de página completam o quadro.
O código de três dígitos é a resposta mais objetiva que um servidor pode dar, e cada faixa aponta para um responsável diferente. Saber ler a faixa já elimina metade das hipóteses erradas.
Um detalhe que confunde muita gente: 4xx e 5xx não significam que o servidor está fora do ar. Ele respondeu, e respondeu rápido o bastante para dizer que algo deu errado. Fora do ar mesmo é quando nada volta. Para mapear onde os 404 se acumulam dentro do site, o verificador de links quebrados percorre as páginas e lista as ocorrências. Se a suspeita for de bloqueio por reputação, vale consultar a pesquisa em listas negras.
Qualquer ferramenta que busca uma URL fornecida pelo usuário é alvo clássico de abuso, porque um atacante pode pedir que o servidor consulte endereços internos aos quais só ele tem acesso. A proteção começa na resolução: o host vira IP antes da conexão, e qualquer resultado em faixa privada, de loopback, link-local ou reservada é recusado, incluindo o endereço de metadados de nuvem 169.254.169.254.
A conexão é então fixada nesse IP já validado, para que ninguém troque o destino depois da checagem. Só http e https são aceitos, cada alvo de redirecionamento passa pela mesma validação e existem tetos de tempo, tamanho e número de saltos. É por isso que a ferramenta se recusa a consultar localhost ou um IP de rede interna, mesmo que a intenção seja legítima.
Nenhuma ferramenta de status conta a história inteira, e vale saber onde esta para. A checagem parte de um único lugar, o nosso servidor, então ela responde se o site está no ar a partir daqui. Uma queda regional ou um bloqueio geográfico exige sondas distribuídas em vários países, o que é um tipo diferente de serviço.
Um 403 ou 429 vindo de serviço de proteção antibot pode significar que o verificador foi barrado, não que o site caiu; a mesma página talvez abra normalmente no seu navegador. A ferramenta também testa HTTP de verdade, e não ping: um servidor pode responder ping com o site quebrado, ou bloquear ping com o site funcionando perfeitamente. Se quiser comparar os dois comportamentos, o teste de ping online e o conversor de domínio para IP ajudam a separar camada de rede de camada de aplicação.
Por fim, a detecção de servidor, CDN e cabeçalhos de segurança é sempre o melhor esforço possível: esses cabeçalhos podem ser removidos, alterados ou forjados por um proxy no caminho. Trate o resultado como forte indício, não como prova.
É uma ferramenta que envia uma requisição HTTP real para uma URL e informa se o servidor respondeu, com qual código e em quanto tempo. Além do estado, ela mostra a cadeia de redirecionamentos, o certificado e os cabeçalhos da resposta.
A aba de lote aceita até vinte URLs, uma por linha. Cada resultado aparece em um cartão próprio, com filtro por classe de status e exportação do lote inteiro em CSV.
Porque o navegador não consegue ler o código real de outro domínio. Requisições entre origens diferentes voltam como resposta opaca, com status 0 e sem cabeçalhos, então a checagem precisa sair de um servidor, que não tem essa restrição.
Fora do ar é quando nada volta, por falha de conexão ou tempo esgotado. Um 404 ou um 500 significa que o servidor está de pé e respondeu, só que a página tem problema.
O HEAD pede apenas os cabeçalhos, sem o corpo da página, o que torna a checagem mais rápida e leve. Quando o servidor recusa o HEAD com 405 ou não responde, a ferramenta repete a consulta com um GET normal.
Não. A checagem parte de um único ponto, então ela confirma o estado do site a partir do nosso servidor. Identificar indisponibilidade regional ou bloqueio geográfico exige uma rede de sondas distribuídas.
Provavelmente um serviço de proteção antibot barrou a requisição do verificador. Nesse caso o 403 fala sobre o filtro, não sobre a saúde do site, mesmo com o user-agent de navegador que a ferramenta usa.
Ela divide a requisição em consulta de DNS, conexão TCP, handshake TLS, espera do servidor e download, desenhados em proporção. Assim dá para ver se a lentidão foi processamento no servidor ou latência de rede.
Como referência geral, a documentação do web.dev sugere que a maioria dos sites busque um tempo até o primeiro byte de 0,8 segundo ou menos. Valores acima disso costumam aparecer como alerta em ferramentas de performance.
O teto evita que a ferramenta fique presa em cadeias muito longas ou em loops. Quando uma URL aponta de volta para outra já visitada, o loop é detectado e a checagem para ali.
Não. Ela é uma checagem leve, feita para pegar problemas óbvios como certificado vencido ou prestes a vencer. Para inspeção detalhada, use o verificador de SSL ou o decodificador de certificados.
Trate como indício forte, não como prova. Cabeçalhos como Server e os marcadores de CDN podem ser ocultados ou forjados por um proxy, então a detecção é sempre o melhor esforço possível.
Não. Não existe cadastro, chave de API nem limite diário escondido. Cole a URL, clique em "Verificar status" e leia o resultado.
Exporte o CSV do lote a cada rodada e compare os arquivos entre si. Muita gente combina essa rotina com o teste rápido de site fora do ar e o verificador de redirecionamento www para acompanhar mudanças de configuração ao longo do tempo.