Monitoramento de disponibilidade de sites a partir de mais de 300 localidades no mundo todo

Os seis cartões acima são onde a maioria das contas começa. O catálogo completo tem quatorze tipos de monitor, e todos compartilham esta mesma frota de localidades, este protocolo de confirmação e este roteamento de alertas - você não usa uma ferramenta para uptime e outra para certificados.

As verificações de rede rodam a partir da frota pública de mais de 300 localidades. As verificações de infraestrutura - consulta ao banco de dados, contador de desempenho e SNMP - passam por agentes dedicados, porque o que elas precisam são credenciais e acesso à sua rede, não geografia.

Isso importa porque os motivos mais comuns para uma verificação «falhar» não têm nada a ver com o seu servidor:

• O caminho quebrou, não o site. Um provedor de trânsito roteia mal por noventa segundos enquanto todas as outras redes ainda chegam até você.
• O site quebrou, mas só para algumas pessoas. Um nó de CDN serve erros desatualizados em uma região, ou uma regra de firewall bloqueia um país - e um ponto de observação no lugar errado diz que «está tudo bem».
• A sonda quebrou. Sem uma segunda opinião, um nó ruim e um site ruim parecem idênticos.

O monitoramento distribuído responde aos três casos da mesma forma: perguntar a vários lugares sem relação entre si e depois comparar. Para fazer essa comparação uma vez, agora mesmo, use a verificação HTTP gratuita a partir de várias localidades.

1. O monitor vence. Os intervalos vão de um minuto a 24 horas, com três como padrão, e o trabalho devido é assumido continuamente, e não em janelas de lote.
2. Uma localidade é escolhida entre os grupos que você selecionou. Você escolhe grupos, não máquinas, então uma verificação alterna dentro do grupo em vez de ficar presa a uma única máquina.
3. A verificação é executada. A localidade faz a requisição real - requisição HTTP, ping ICMP, handshake TCP, carregamento de página no navegador - e devolve o resultado, o detalhamento dos tempos e, quando se aplica, o corpo da resposta.
4. Uma mudança de estado inicia uma confirmação, não um alerta. Somente uma mudança confirmada abre ou fecha um episódio de indisponibilidade.

Os grupos para os quais um monitor pode ser apontado têm nome e podem ser selecionados na interface e na API:

Um monitor novo começa na Europa Ocidental, na Europa Oriental e na América do Norte. Os grupos se combinam e se subtraem: allworld com -russia significa «em todo lugar, exceto a Rússia», que é como você mantém o roteamento nacional de um país fora dos seus alertas.

Uma única verificação com falha nunca envia um alerta. Quando um resultado diverge do estado atual do monitor, o HostTracker abre uma sessão de confirmação e segura o alerta até que outras localidades respondam:

1. Esperar dez segundos. Um alvo que acabou de mudar é o que menos precisa de uma rajada de tráfego extra, e muitas instabilidades terminam antes do décimo segundo.
2. Abrir a reverificação em leque. Até sete localidades são sorteadas de um grupo embaralhado e disparadas com dois segundos de intervalo, de modo que as reverificações se espalham no tempo e também na geografia. Se há poucas localidades confiáveis livres, o quórum é completado até o mínimo de três.
3. Classificar as respostas antes de contá-las. Uma localidade que não conseguiu executar a verificação não conta e não é penalizada. Uma que devolve lixo também não conta, é marcada e uma substituta é enviada.
4. Aplicar a regra de concordância. Por padrão, a maioria decide. Por monitor, você pode exigir que pelo menos um número definido de localidades informe queda, exigir concordância total nos dois sentidos ou exigir concordância total para uma queda enquanto as recuperações são confirmadas por maioria.
5. Pontuar as localidades em relação ao veredito. Uma localidade que continua discordando recebe um ponto de desconfiança com uma contagem regressiva, é ignorada enquanto ela durar e volta a ganhar espaço à medida que a contagem regressiva decai. É assim que um nó instável se aposenta sozinho.
6. Se nada contável voltou, ninguém é acordado. A sessão termina sem veredito e a verificação base é tentada de novo mais tarde.

Ele também tem um interruptor: uma verificação cujo resultado já é definitivo por si só (uma consulta ao banco de dados devolveu a linha ou não devolveu) pula a confirmação por completo.

O argumento mais forte a favor do monitoramento em múltiplas localidades não é a queda que todo mundo percebe, mas a que só algumas pessoas percebem. No ar na Europa e fora do ar na América do Norte se parece com isto:

É ilustrativo, mas tem a forma que um resultado real por localidade carrega. A regra de maioria padrão não chama isso de queda global, porque não é uma. O que ela faz é registrar quais localidades falharam, em que segundo e com qual erro - evidência com carimbo de data e hora, coletada de fora da rede do seu provedor, e é isso que a torna utilizável em um chamado de suporte.

Para ser avisado de uma falha regional em vez de apenas registrá-la: ajuste a regra de confirmação para «pelo menos este número de localidades informa queda» ou execute um segundo monitor fixado nessa região, onde a falha é a maioria. Está investigando um host agora? Um teste de ping global mostra esse quadro com um clique.

O alerta é guiado pelo atraso próprio de cada contato, não por uma regra global. Cada contato escolhe quando quer saber de uma queda: imediatamente, ou após 3, 5, 15, 30 ou 60 minutos de falha contínua, ou após 3, 6, 12 ou 24 horas. Essa escada transforma uma lista de contatos em uma política de escalonamento, sem um produto de plantão separado - minuto 0 para o canal da equipe, minuto 5 para o telefone do engenheiro de plantão, minuto 30 para o líder de engenharia, hora 3 para o dono da conta.

Canais para qualquer degrau: e-mail, SMS, chamada de voz, push do navegador, Slack, Telegram, Discord, Viber e webhooks assinados - o webhook é o meio pelo qual os alertas chegam a um gerenciador de incidentes, a um sistema de tickets ou a qualquer ferramenta interna com uma URL de entrada.

Um monitoramento que só alerta é meio produto. A outra metade é o registro que ele deixa - o que você usa em uma disputa com a hospedagem, em um pedido de crédito de SLA ou em uma revisão pós-incidente.

• Resultados de verificação por localidade com status, tempo de resposta e texto do erro, mantidos como histórico e não apenas como estado atual.
• Episódios de indisponibilidade com um início confirmado, um fim confirmado e o rastro de confirmação por trás de ambos.
• Relatórios de uptime agendados, enviados por e-mail na cadência que você definir.
• Uma exportação de SLA e um selo de uptime publicados diretamente de uma página de status.
• Janelas de manutenção, para que o trabalho planejado não contamine o número de disponibilidade que você terá de defender depois.

A evidência externa tem peso justamente por ser externa: um provedor pode descartar os seus próprios logs de servidor, mas um registro com carimbo de data e hora de falhas vistas por várias redes independentes, nenhuma delas sua, é mais difícil de contestar.

A maneira mais rápida de reduzir o volume de suporte durante um incidente é parar de obrigar as pessoas a perguntar. Uma página de status transforma monitores que você já executa em componentes públicos, atualiza-os a partir dos mesmos resultados confirmados que disparam os seus alertas e é hospedada para você em um endereço próprio - sem hospedagem extra e sem trabalho de DNS. Incidentes e janelas de manutenção são publicados nela, e os visitantes podem se inscrever.

As páginas de status estão incluídas em todos os planos, inclusive no gratuito, e publicar sob o seu próprio domínio também. O HostTracker executa a sua na mesma estrutura - status.host-tracker.com é um exemplo ao vivo - e a visão geral das páginas de status cobre o resto.

Toda afirmação desta página pode ser testada sem uma conta, porque as ferramentas instantâneas gratuitas rodam na mesma frota dos monitores pagos. Aponte uma para um site que você sabe que está saudável, depois para um que você sabe que não está, e leia você mesmo os resultados por localidade.

• Verificação HTTP gratuita a partir de várias localidades - código de status, tempo de resposta e cabeçalhos por localidade.
• Executar um teste de ping global - alcance, latência e perda de pacotes na camada de rede, onde os problemas de roteamento aparecem primeiro.

São onze dessas ferramentas gratuitas, cada uma a versão manual de um tipo de monitor que você pode depois colocar em um agendamento.

As localidades são um parâmetro de primeira classe, não uma configuração escondida em um formulário. Executando uma verificação a partir de regiões nomeadas via REST:

curl -X POST https://api2.host-tracker.com/check \
  -H "Authorization: Bearer $HT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "type": "http", "pools": ["westeurope", "asia"]}'

Os identificadores da tabela de regiões vão em pools, e os mesmos valores funcionam quando você cria um monitor agendado. Em torno dessa superfície REST há bibliotecas oficiais para TypeScript, Python, Go e .NET, o cliente de linha de comando ht, uma GitHub Action e um servidor MCP para que um assistente de IA possa criar monitores e ler resultados diretamente - tudo gerado a partir de um único documento OpenAPI.

Três formas de usar a rede, e a frota é a mesma em todas - o plano gratuito não é verificado a partir de menos lugares que os pagos.

O teste é a forma honesta de avaliar isto: 30 dias, cem monitores, sem cartão - o suficiente para rodar o HostTracker ao lado do que você usa hoje e comparar os alertas que os dois realmente enviaram. Limites completos por plano: planos de monitoramento de sites do HostTracker.

Somente colunas que podem ser conferidas em uma página publicada. Extraído dos preços e da documentação de cada fornecedor, agosto de 2026 - confirme tudo de que uma decisão dependa.

Onde não estamos à frente, a tabela diz: o plano gratuito do UptimeRobot traz mais monitores que o nosso, e o servidor MCP hospedado deles saiu com OAuth antes do nosso. Os motivos para escolher esta rede estão nas três primeiras linhas.

Detalhes de rede, protocolo e planos desta página revisados pela última vez em 30 de agosto de 2026. O HostTracker opera esta rede de monitoramento distribuída desde 2004.