Monitorização de site grátis com alertas em tempo real

Porque monitorizar a disponibilidade das suas URLs?

Um uptime de 99,9 % tolera 43 minutos de indisponibilidade por mês. Resta saber quando acontecem. Sem monitorização automática, uma queda é descoberta por um email de cliente, muitas vezes várias horas depois do início do incidente. Enquanto isso, o funil de conversão está interrompido, os formulários deixaram de ser enviados e o Googlebot regista 5xx.

O mecanismo é simples: uma requisição enviada em intervalos regulares, uma resposta registada, um alerta quando ela se afasta do esperado.

Quatro razões para monitorizar os seus endpoints:

• Detetar antes dos utilizadores: uma falha da aplicação ou uma pane do alojamento aparece em poucos minutos, não no primeiro ticket de suporte.
• Proteger o posicionamento: erros 5xx prolongados em páginas indexadas degradam o crawl e a classificação.
• Cobrir as jornadas críticas: página de checkout, endpoint REST, formulário de contacto.
• Enquadrar as migrações: o histórico de checks mostra quando a regressão apareceu.

Como usar a monitorização HTTP em 3 passos

Passo 1: Adicionar a URL a ser monitorizada

Introduza a URL completa do endpoint, incluindo o protocolo:

https://captaindns.com/pt/pricing

Comece pelas URLs cuja indisponibilidade se faz sentir de imediato: página inicial, checkout, API pública.

Passo 2: Definir o intervalo e as condições de alerta

Três configurações bastam na maioria dos casos:

• Intervalo de verificação: 5 minutos por predefinição. Uma expressão cron cobre as necessidades específicas (apenas em horário comercial, janela de manutenção eliminada).
• Código HTTP esperado: qualquer código 2xx por predefinição. Informe um código específico se o endpoint tiver de retornar exatamente esse, por exemplo 301 para um redirecionamento ou 401 para um endpoint protegido.
• Alertas por email: uma chave de ativação por monitor. Os emails são enviados para o endereço da sua conta CaptainDNS, sem nenhum destinatário para informar por monitor. Nos planos pagos, um webhook HTTPS pode encaminhá-los para o Slack, o Discord ou o PagerDuty.

Passo 3: Executar um check e ler as métricas

Dispare um check imediato para validar a configuração. O resultado aparece em poucos segundos com o código HTTP, o tempo de resposta total e, se for o caso, o código de erro. O painel depois agrega o uptime em 24 h, 7 dias e 30 dias, o tempo de resposta médio e o p95, o heatmap e a lista de incidentes.

Como funciona um check HTTP

Cada check percorre quatro etapas, e cada uma delas pode falhar independentemente das restantes.

1. Resolução DNS

O nome de domínio da URL é resolvido antes de qualquer ligação. Uma falha de resolução (NXDOMAIN, SERVFAIL, timeout) marca o check como dns_error e dispara um alerta.

2. Abertura da ligação e negociação encriptada

Uma ligação TCP é aberta com o IP resolvido. Em HTTPS, o handshake TLS valida a cadeia de certificados, a data de expiração e a correspondência com o hostname. Um certificado expirado ou inválido marca o check como tls_invalid.

3. Requisição HTTP e leitura da resposta

A requisição é enviada (GET por predefinição, ou o método configurado). O CaptainDNS aguarda até o tempo limite configurado, 10 segundos por predefinição e 30 no máximo. A partir daí, o check é marcado como timeout. O código HTTP e o tempo de resposta total ficam registados.

4. Avaliação e envio de alertas

Um check é up se o código HTTP for um 2xx, ou se corresponder exatamente ao código esperado quando informou um; um 5xx, um código fora do esperado, um timeout ou um erro de rede marcam-no como down. Uma transição confirmada de up para down desencadeia um alerta; o retorno a up desencadeia um email de recuperação que encerra o incidente.

Monitorizar o seu site a partir de várias regiões

Um monitor de região única só mostra uma parte da verdade. Se a sua sonda está na Europa e um operador de trânsito transatlântico tem um problema, o site aparece up quando os seus clientes americanos já não conseguem aceder-lhe. Inversamente, um incidente de rede local perto da sonda pode dar a impressão de uma pane global.

O CaptainDNS executa os checks a partir de três zonas, na infraestrutura Fly.io: Europa (eu) para a UE, o Reino Unido e o Norte de África, Estados Unidos (us) para a América do Norte e parte da América Latina, Ásia-Pacífico (apac) para o Japão, a Coreia, o Sudeste Asiático e a Oceania. O número de regiões ativáveis depende do plano: apenas uma (Europa) nos planos de entrada, até três acima disso. Veja os planos e preços.

Três estratégias de deteção de falhas

Ter várias sondas levanta uma questão: a partir de quantas regiões com falha o site deve ser considerado DOWN?

• Consenso (por predefinição): o monitor passa a DOWN se pelo menos metade das regiões falhar. Os falsos positivos ligados a um incidente de rede isolado são filtrados e uma pane real aparece rapidamente.
• Estrito: basta uma única região DOWN. Adequado para monitores críticos (pagamento, API em tempo real) em que qualquer flap regional, mesmo breve, deve ser reportado.
• Unânime: o monitor só passa a DOWN se todas as regiões falharem. Adequado para infraestruturas distribuídas (CDN ativo-ativo, edge compute) que toleram flaps regionais.

Com uma única região ativa, as três estratégias dão o mesmo resultado: a escolha só aparece a partir de duas regiões.

Analisar a postura de segurança do seu site

Um monitor de uptime cobre uma única pergunta: "o site responde?". Nada diz sobre a qualidade do que retorna. Um site pode retornar 200 em 80 ms durante meses com um certificado perto de expirar, um HSTS removido por um deploy de reverse-proxy ou uma CSP que voltou a unsafe-inline. A monitorização de postura cobre esse ponto cego: recalcula periodicamente uma nota de segurança para as URLs já monitorizadas e alerta quando ela se degrada.

Os cinco componentes analisados

• Certificado SSL/TLS: validade, cadeia de confiança, data de expiração, versões de TLS aceites.
• HSTS: presença do cabeçalho, duração max-age, cobertura dos subdomínios, pré-carregamento.
• Cabeçalhos de segurança: CSP, X-Frame-Options, Referrer-Policy e a defesa em profundidade associada.
• Peso da página: volume dos recursos carregados, sinal de higiene de desempenho.
• Reputação (phishing): verificação da URL monitorizada nas bases de ameaças (Google Web Risk, URLhaus, VirusTotal), medida uma vez por dia.

Selecione os componentes a acompanhar, no mínimo um. Desmarcar um componente exclui-o do cálculo sem distorcer a nota: o seu peso é redistribuído entre os componentes restantes.

A nota de 0 a 100 dividida em duas áreas

A nota global é uma média ponderada de Segurança (80 pontos), que cobre o certificado, o HSTS, os cabeçalhos e a reputação, e de Desempenho (20 pontos), que cobre o peso da página. Cada componente é classificado numa categoria legível: Excelente, Bom, A melhorar ou Crítico. A segurança pesa quatro vezes mais, porque um certificado inválido expõe os seus visitantes, enquanto uma página pesada apenas torna tudo mais lento.

Frequência, referência inicial e alertas

Na primeira análise, o CaptainDNS estabelece uma referência sem enviar nenhum alerta. Depois, cada alteração notável dá origem a um resumo componente a componente, e um alerta preventivo é enviado antes de o certificado expirar, em patamares de 30, 14, 7, 3 e 1 dia. Um separador dedicado apresenta a nota atual e o histórico ao longo de 180 dias.

A análise de postura é executada apenas a partir da Europa: o certificado, o HSTS e os cabeçalhos não variam conforme o ponto de observação. Está disponível a partir do plano Solo, com uma frequência mínima e um número de monitores por domínio raiz variáveis conforme o plano (veja os planos e preços).

A pontuação e os seus componentes também podem ser publicados numa status page pública: escolha, monitor por monitor, os elementos visíveis (pontuação de 0 a 100, certificado, HSTS, cabeçalhos, peso da página, reputação). Nada é publicado por predefinição.

Alertas por email e webhooks

Um alerta é enviado assim que um check sai das condições esperadas. Veja o resumo por tipo de erro.

Três freios contra o ruído

Um site em flap pode gerar dezenas de alertas por hora. Três mecanismos evitam isso:

1. Confirmação em 2 falhas consecutivas: por predefinição, nenhum alerta é enviado antes de dois checks com falha seguidos. O limiar é ajustável de 1 a 10 falhas na configuração do monitor.
2. Espaçamento progressivo dos lembretes: um alerta no início do downtime, depois no máximo um lembrete por hora durante as primeiras 24 horas do incidente, e um lembrete a cada 24 horas depois disso. Um alerta de recuperação encerra o incidente quando o site volta ao ar.
3. Desativação automática: um dia conta como perdido quando nenhum check desse dia teve êxito. No 5º dia perdido consecutivo, um email de aviso é enviado; no 7º, o monitor é desativado.

O email de alerta contém a URL em questão, o código HTTP ou o tipo de erro, a latência do último check válido, o timestamp UTC e local, e um link para o painel. Nenhum pixel de rastreamento.

Webhooks HTTP

O email nem sempre basta para reencaminhar os alertas para o Slack, o Discord, o PagerDuty ou um sistema interno de gestão de incidentes. Nos planos pagos, um ou mais endpoints HTTPS recebem os eventos em POST JSON, assinados com um segredo partilhado para validar a origem do lado do recetor. Cada webhook assina as categorias que lhe interessam, entre as três disponíveis: Monitoring, Deployment e DNS. Os alertas de disponibilidade pertencem a Monitoring e podem ser reencaminhados para um canal Slack de ops, enquanto um segundo webhook recebe apenas os eventos Deployment. Em caso de falha de entrega, o CaptainDNS tenta novamente com backoff exponencial e regista cada tentativa.

Métricas de uptime, latência p95 e heatmap de 30 dias

O painel agrega os checks brutos em seis métricas.

A latência p95 é o melhor indicador do desempenho percebido. A média esconde os picos; o p95 mostra o que os seus utilizadores sentem nos 5 % piores casos.

Heatmap de 30 dias

O heatmap apresenta os últimos 30 dias na forma de uma grelha colorida. Cada célula cobre um dia UTC completo, nunca uma janela mais fina, e recebe a cor do uptime do dia: verde acima de 99,5 %, laranja entre 90 e 99,5 %, vermelho abaixo de 90 %, cinzento na ausência de dados.

Histórico e retenção

Cada check individual permanece consultável durante 30 dias no plano gratuito: timestamp, código HTTP, tempo de resposta total, eventual código de erro. Passado esse prazo, os checks unitários são eliminados automaticamente. A retenção detalhada aumenta nos planos superiores, dentro do limite de 90 dias aplicado a todos os planos. Os agregados diários (uptime, latência média) não são eliminados; a profundidade de histórico legível numa status page pública depende do plano, de 30 dias no plano gratuito a várias centenas de dias acima disso. Eliminar um monitor apaga todos os seus dados.

Casos de uso reais

Caso 1: um deploy que derruba a página inicial

Sintoma: um deploy de sexta-feira à noite entra em produção. Na segunda-feira de manhã, um cliente avisa que o formulário de contacto retorna um erro desde o fim de semana.

Diagnóstico: o histórico dos checks mostra uma transição para down com códigos 500 às 21h12 de sexta-feira, seguida de 61 horas de downtime contínuo. O alerta por email da mudança de estado tinha de facto sido enviado, mas para um endereço que ninguém mais consultava.

Ação: reencaminhar os alertas da categoria Monitoring para um webhook Slack, além do email, e adicionar um monitor dedicado ao endpoint do formulário em vez de monitorizar apenas a página inicial.

Caso 2: falso alerta num incidente de rede regional

Sintoma: um alerta DOWN chega às 3 da manhã. O site responde normalmente a partir da sua estação de trabalho.

Diagnóstico: o monitor corre em três regiões com estratégia Estrito. O detalhe por região mostra timeout apenas a partir da sonda apac, durante 12 minutos, com eu e us em 200. Não é uma pane do site, mas um incidente de trânsito local.

Ação: mudar este monitor para Consenso, que exige pelo menos metade das regiões com falha. Reservar o Estrito para os endpoints em que um flap regional já é um incidente para o cliente, como uma API de pagamentos.

Caso 3: certificado expirado num domingo

Sintoma: o site responde 200 há semanas, o uptime está em 100 % e, ainda assim, os navegadores exibem um aviso de segurança.

Diagnóstico: a renovação automática do certificado falhou silenciosamente, depois de uma alteração na configuração do reverse-proxy. O monitor de uptime nada sinalizou antes da expiração: constata um certificado inválido depois de passada a data, nunca nas semanas anteriores.

Ação: ativar a monitorização de postura neste monitor. O alerta de expiração é enviado em patamares de 30, 14, 7, 3 e 1 dia, e a nota cai assim que o certificado ou o HSTS regride.

Comparativo das ferramentas de monitorização de sites

O CaptainDNS não é uma ferramenta de monitorização especializada: é um painel de DNS, SPF, DKIM, DMARC e blacklists ao qual se somam a monitorização HTTP e a postura de segurança, com um plano de dados operado na União Europeia. A decisão depende, portanto, do escopo. Se só monitoriza uptime e precisa de dezenas de monitores gratuitos, uma ferramenta especializada como o UptimeRobot atende melhor à necessidade. Se procura status pages muito personalizáveis, o BetterStack vai mais longe nesse aspeto. O CaptainDNS faz sentido quando a monitorização HTTP estende uma monitorização DNS e de email já instalada, e quando a localização europeia do tratamento importa. Cotas e preços exatos na página dos planos e preços.

Cotas, limites e planos disponíveis

O plano gratuito inclui 1 monitor HTTP verificado a cada 5 minutos a partir da Europa, ou seja, 288 checks por dia, com alertas por email ilimitados, 30 dias de histórico detalhado, heatmap, latência p95 e 1 status page pública, sem cartão de crédito. Os planos pagos aumentam o número de monitores, o número de regiões ativáveis, a duração da retenção e o número de webhooks simultâneos, e desbloqueiam a monitorização de postura a partir do Solo. A tabela completa é mantida atualizada na página dos planos e preços, que prevalece em caso de divergência com esta página.

Monitorizar o seu site a partir da Europa: soberania e conformidade

A monitorização HTTP é um tratamento de dados: transmite URLs e, por vezes, cabeçalhos de autenticação. O CaptainDNS opera o seu plano de dados a partir da União Europeia, com uma sonda Europa na França e na Alemanha, uma base de dados PostgreSQL e backups em França, e uma equipa técnica europeia. As sondas Estados Unidos e Ásia-Pacífico são opcionais e limitam-se a executar os checks: os resultados são repatriados para a base europeia, que continua a ser o armazenamento primário seja qual for o plano. O painel não utiliza nenhum cookie de rastreamento nem script de analytics de terceiros. O cliente é o responsável pelo tratamento dos seus monitores e o CaptainDNS atua como subcontratante nos termos do artigo 28 do RGPD; o DPA está disponível mediante solicitação.

Limites da monitorização HTTP

A monitorização HTTP do CaptainDNS não cobre as seguintes necessidades:

• Monitorização TCP bruto em portas não HTTP (SMTP, FTP, base de dados).
• Transações em várias etapas: jornada do utilizador por várias páginas com asserções sucessivas.
• Sondas fora das três zonas (Europa, Estados Unidos, Ásia-Pacífico): nem América do Sul, nem África, nem Médio Oriente.
• Endpoints não públicos: uma URL atrás de uma VPN ou de um firewall privado continua inacessível a partir das nossas sondas.

Os alertas para Slack, Discord, PagerDuty e Opsgenie não passam por integrações nativas: são obtidos por meio dos webhooks HTTPS, deixando que o destino cuide da formatação final.

FAQ - Perguntas frequentes

P: O que é a monitorização de um site?

R: Monitorizar um site consiste em verificar continuamente a disponibilidade e a latência de uma URL HTTP. A ferramenta envia uma requisição em intervalos regulares, regista a resposta e dispara um alerta em caso de falha. Assim, a queda é detetada antes que os seus utilizadores percebam.

P: Com que frequência o CaptainDNS verifica a minha URL?

R: Por predefinição, um check HTTP a cada 5 minutos em cada um dos seus monitores, ou seja, 288 verificações por dia. Uma expressão cron permite personalizar a cadência: check a cada minuto em horário comercial, janela de manutenção eliminada.

P: Como receber um alerta quando o meu site cai?

R: Ative os alertas por email na criação do monitor: eles são enviados para o endereço da sua conta CaptainDNS, sem precisar de informar destinatário. Assim que uma falha é confirmada (5xx, timeout, erro DNS, certificado TLS inválido), um alerta é enviado. Os lembretes seguintes têm pelo menos uma hora de intervalo, e um email de recuperação encerra o incidente quando o site volta ao ar.

P: O que significa um uptime de 99,9 %?

R: Um uptime de 99,9 % tolera cerca de 8 horas e 45 minutos de indisponibilidade por ano, ou seja, 43 minutos por mês. É o limiar habitualmente adotado em produção. Com 99,99 %, o orçamento cai para 52 minutos por ano.

P: O CaptainDNS é grátis para monitorizar o meu site?

R: O plano gratuito inclui 1 monitor HTTP verificado a cada 5 minutos, alertas por email ilimitados, o heatmap de 30 dias e a latência p95, sem cartão de crédito. As cotas dos outros planos estão detalhadas na página de preços.

P: Posso monitorizar uma URL autenticada ou um endpoint privado?

R: Sim, no caso das URLs públicas. Os cabeçalhos HTTP personalizados (Authorization, X-API-Key) permitem consultar um endpoint protegido por token. Uma URL atrás de uma VPN ou de um firewall privado continua inacessível a partir das nossas sondas.

P: Como partilhar os meus resultados de monitorização?

R: Associe o seu monitor a uma status page pública do CaptainDNS. A página expõe o uptime, a latência e o histórico de incidentes aos seus clientes, sem lhes dar acesso ao seu painel privado.

P: O que é a nota de postura de segurança?

R: É uma avaliação de 0 a 100 recalculada periodicamente a partir de cinco componentes: certificado SSL/TLS, HSTS, cabeçalhos de segurança, peso da página e reputação (phishing). Ela divide-se em Segurança (80 pontos) e Desempenho (20 pontos), e alerta a cada regressão ou antes de o certificado expirar. Disponível a partir do plano Solo.

P: Quais componentes a postura analisa e com que frequência?

R: Certificado SSL/TLS, HSTS, cabeçalhos de segurança HTTP, peso da página e reputação (phishing). Escolha os componentes acompanhados (pelo menos um) e a frequência, de uma vez por hora a uma vez por dia conforme o plano. O peso da página e a reputação continuam a ser medidos uma vez por dia, no máximo.

Ferramentas complementares

Recursos úteis

• Google SRE Book: Service Level Objectives (definição de referência de SLA, SLO e orçamentos de erro por trás dos 99,9 %)
• RFC 6797 (especificação do HTTP Strict Transport Security, um dos componentes da nota de postura)
• MDN: Content-Security-Policy (documentação do cabeçalho CSP e das suas diretivas)
• Documentação da Let's Encrypt (renovação automática e tempo de vida dos certificados TLS)
• CA/Browser Forum (organismo que define os requisitos de base dos certificados públicos, incluindo a sua validade máxima)
• Fly.io: regiões (lista das regiões da infraestrutura onde correm as sondas)