Como monitorar páginas de status de fornecedores para receber alertas de indisponibilidade

Pouco antes da meia-noite, no horário do Pacífico, em 19 de outubro de 2025, uma condição de corrida na automação de DNS do Amazon DynamoDB deixou o endpoint regional do serviço em us-east-1 com um registro DNS vazio. Qualquer aplicação que dependesse do DynamoDB naquela região começou a falhar, e a instabilidade se espalhou para outros serviços da AWS que dependiam dele. Segundo o relatório oficial da própria AWS, o incidente durou cerca de quatorze horas e meia.

Naquela manhã, muitas equipes operavam com servidores em perfeito estado. Seus monitores de uptime continuavam verdes enquanto o provedor de autenticação, o processador de pagamentos ou o serviço de disparo de e-mails enfrentavam graves problemas. A maioria das indisponibilidades é menor: seu provedor de e-mail atrasa os envios em quarenta minutos, o suporte recebe uma enxurrada de chamados dizendo «meu link de redefinição de senha não chega» e alguém finalmente descobre a página de status do fornecedor, que já exibe «Desempenho degradado» há meia hora.

Eu trabalho no Page Deltas, uma ferramenta que monitora páginas web públicas e avisa quando elas mudam de acordo com o que você precisa saber; tenha isso em mente ao ler as comparações abaixo. Este artigo explica como direcionar o monitoramento para as páginas de status dos fornecedores dos quais você depende: qual URL escolher, como redigir um brief que elimine o ruído, para onde enviar o alerta e em que ponto essa abordagem encontra seus limites.

Por que suas ferramentas de monitoramento continuam verdes

Seu monitor de uptime pergunta se o seu próprio site está respondendo, e durante a queda de um fornecedor externo ele geralmente responde perfeitamente. Seu APM registrará um pico de erros nas chamadas ao fornecedor, mas não poderá dizer se o problema está no seu código ou no serviço deles. Essa é a pergunta que uma página de status responde, e a resposta muda sua próxima decisão: você não reverte o deploy feito há uma hora; avisa ao suporte que se trata de uma instabilidade externa conhecida e avalia atualizar sua própria página de status.

Por que não se inscrever diretamente na página do fornecedor? Você deve fazer isso se for suficiente para você. Muitas páginas de status utilizam o Atlassian Statuspage e oferecem alertas por e-mail, SMS, Slack, Teams ou webhooks, dependendo do que o fornecedor ativou. A dificuldade surge no oitavo fornecedor: cada inscrição é uma configuração isolada que muitas vezes vai parar na caixa de entrada de uma única pessoa, cada fornecedor formata mensagens de um jeito e filtrar apenas os componentes que você utiliza nem sempre é possível. Alguns fornecedores mantêm páginas próprias sem qualquer botão de inscrição.

Um monitor de alterações web oferece um padrão único para qualquer fornecedor: você cola a URL da página de status, descreve o que importa em uma frase e cada alerta chega no mesmo canal com o mesmo formato.

Quais páginas você deve monitorar?

Escolha a página que mostra o status em tempo real, normalmente status.fornecedor.com. Não selecione a página inicial institucional nem a página comercial sobre confiabilidade. A maior parte das páginas de status SaaS segue o mesmo padrão: uma lista de componentes acompanhada do status operacional, um banner de incidentes ativos, avisos de manutenções programadas e um histórico recente com link para o arquivo completo.

Comece pelas dependências cujo impacto seus clientes sentiriam imediatamente. Para a maioria das equipes de software, essa lista é curta.

Se puder monitorar apenas algumas, comece pelo topo da lista. Falhas de pagamento e autenticação se transformam em tickets de suporte em minutos, enquanto uma lentidão na CDN pode aparecer apenas nas suas métricas técnicas. As 10 URLs do plano gratuito cobrem todas as cinco linhas e ainda deixam margem para os complementos abaixo.

Outras duas páginas são muito úteis. A página de histórico (frequentemente /history) é uma excelente segunda verificação para um fornecedor essencial: uma indisponibilidade curta pode começar e ser resolvida entre duas checagens da página principal, mas ficará registrada no histórico, garantindo que você tome ciência depois. Durante um incidente longo, você também pode adicionar a URL do incidente específico como um monitor temporário para acompanhar cada atualização. Remova-o assim que for resolvido para não comprometer seu limite de URLs.

Configuração passo a passo

A configuração leva cerca de cinco minutos e segue o mesmo fluxo do nosso guia de monitoramento de changelogs, com um brief customizado.

1. Crie uma conta e configure um canal

Cadastre-se gratuitamente, acerte Canais e adicione o local onde os alertas devem chegar. Sugiro criar um canal dedicado como #vendor-status em vez de publicar no #engineering, onde as mensagens ficariam perdidas. Slack, Discord e Microsoft Teams aceitam uma URL de webhook de entrada. No Teams, clique com o botão direito no canal, selecione Conectores, depois Webhook de entrada, Configurar e cole a URL no Page Deltas. No caso do e-mail, o destinatário precisa confirmar uma mensagem de verificação antes. Clique em Enviar teste em cada canal para validar o recebimento.

2. Adicione um monitor com um brief

Clique em Novo monitor e cole a URL da página de status. Mantenha um fornecedor por monitor para que cada brief mencione os componentes específicos daquele fornecedor, e caso equipes distintas acompanhem fornecedores diferentes, associe um canal diferente a cada monitor.

As páginas de status mudam com mais frequência do que parece, mesmo em dias sem incidentes: as porcentagens de disponibilidade variam, as marcações de «última atualização» avançam e a lista de incidentes recentes rola um dia com uma nova linha de «Nenhum incidente relatado». Manutenções programadas são divulgadas com semanas de antecedência. Uma ferramenta comum de diff geraria alertas desnecessários para tudo isso.

A descrição do monitor é o prompt que nosso LLM analisa para determinar se a alteração é relevante. Escreva como se estivesse orientando um colega de trabalho que fosse acompanhar a página para você. Para um provedor de e-mail, algo assim funciona com precisão:

Página de status do nosso provedor de e-mail. Usamos apenas os componentes
Email API e Webhooks na região US.
Alerte-me quando um novo incidente for publicado afetando esses componentes
ou essa região, quando seu status ou gravidade mudar, ou quando for resolvido.
Alerte-me se qualquer um dos dois componentes deixar de estar em Operational.
Ignore porcentagens de uptime, marcações de tempo de "última atualização",
as linhas diárias de "Nenhum incidente relatado" e incidentes em outras regiões.
Mencione manutenção programada apenas se começar em até 48 horas.
Resuma o componente afetado, o status atual e a atualização mais recente.

A instrução de exclusão faz a maior parte do trabalho pesado. Se você omiti-la, passará sua primeira semana recebendo alertas à meia-noite pelo simples avanço da lista diária de incidentes.

No caso de um grande provedor de nuvem, os nomes de região e serviços são ainda mais determinantes. Um painel público de nuvem abrange centenas de serviços em dezenas de regiões, e em uma semana típica sempre há algo degradado em algum lugar. Cite expressamente as regiões e serviços que você utiliza e peça para ser notificado somente sobre eles.

3. Deixe a primeira checagem estabelecer a referência

Um novo monitor realiza sua primeira verificação logo após a criação. Essa consulta inicial armazena o ponto de partida, portanto você não receberá alertas no primeiro minuto, a menos que a página sofra alterações entre duas checagens. Abra o monitor em seguida e veja a captura de tela para ter certeza de que ela englobou a lista de componentes esperada.

4. Faça uma verificação manual ao notar algo estranho

No Page Deltas você não define um intervalo fixo. O agendamento é adaptativo: páginas com movimentação constante são checadas com mais frequência, e os planos pagos têm prioridade nas filas de processamento. Como uma página de status fica quieta a maior parte do tempo, se sua taxa de erros subir e você suspeitar de um fornecedor, clique em Verificar agora no monitor dele. A mesma ação está disponível via API, limitada a uma vez por minuto por monitor:

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

O que fazer quando um alerta chegar

Quando uma alteração corresponder ao seu brief, você receberá uma mensagem clara com um resumo em linguagem natural e capturas de tela de antes e depois. Se utilizar o webhook assinado, o payload terá esta estrutura (os valores são ilustrativos para o exemplo):

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "Status do provedor de e-mail",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "Novo incidente: atraso no envio de e-mails na região US. Email API mudou de Operational para Degraded Performance. Status: Investigando.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

A primeira pessoa que visualizar o alerta deve responder na conversa explicando o impacto prático. O time de suporte pode fixar uma resposta sobre incidente conhecido antes que as mensagens comecem a se acumular. O engenheiro de plantão pode descartar a hipótese de um deploy com problemas, e se a falha for visível aos clientes, atualize sua própria página de status para que eles saibam do ocorrido primeiro por você.

Se a sua equipe utiliza o PagerDuty ou outra ferramenta de resposta a incidentes, o webhook assinado permite alimentar esses sistemas por meio de uma pequena integração intermediária. Como nosso payload difere do formato nativo do PagerDuty, poucas linhas em uma função serverless bastam para checar a assinatura e repassar o evento:

import crypto from "node:crypto";

export async function handle(rawBody, signature) {
  const expected = "sha256=" + crypto
    .createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
    .update(rawBody).digest("hex");
  if (signature.length !== expected.length ||
      !crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return 401;
  }
  const alert = JSON.parse(rawBody);
  await fetch("https://events.pagerduty.com/v2/enqueue", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      routing_key: process.env.PAGERDUTY_ROUTING_KEY,
      event_action: "trigger",
      dedup_key: alert.change_id,
      payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
      links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
    }),
  });
  return 200;
}

Gere o hash sobre o corpo bruto antes de convertê-lo em JSON, caso contrário a assinatura não baterá. A documentação de canais traz todos os detalhes. Cada alerta é disparado uma única vez por canal sem novas tentativas automáticas: para fornecedores críticos, configure um segundo canal de tipo diferente (Slack somado a e-mail, por exemplo) caso o Slack ou a função intermediária passem por instabilidades.

Limitações que você precisa saber

Essa abordagem informa o que um fornecedor comunicou publicamente, o que traz algumas limitações objetivas antes de você depender unicamente dela.

Os fornecedores frequentemente demoram para admitir e publicar incidentes. Seus próprios gráficos de erros apontarão problemas antes que a página de status oficial acuse qualquer coisa; portanto, encare o alerta como uma confirmação e não como seu primeiro aviso de emergência. Além disso, essa solução não substitui testes sintéticos nem o monitoramento de disponibilidade da sua própria API. Estes indicam que o seu produto está com problemas; a página de status esclarece o porquê.

Entre verificações, as alterações são detectadas no ciclo agendado seguinte, sem um intervalo rígido fixo. Para aquele ou aqueles dois fornecedores onde cada minuto conta, mantenha também a notificação nativa do próprio serviço e utilize o Page Deltas para o restante da lista. Por fim, só conseguimos ler páginas públicas: um status restrito à parte interna de um painel de administração fica inacessível por enquanto.

Comparamos o texto de cada página. Se um fornecedor representar o status unicamente por um ícone colorido sem alterar nenhuma palavra, nós não conseguiremos detectar. O Visualping permite monitorar uma área gráfica de pixels na tela e é a melhor opção para esse cenário. Por fim, se a própria página de status cair, as verificações falham em vez de alertar, e após 10 falhas consecutivas o monitor é pausado automaticamente e seus administradores recebem um aviso.

Comece com três fornecedores

Identifique os três fornecedores cuja indisponibilidade traria mais prejuízos — provavelmente pagamentos, autenticação e e-mail. Cole as URLs de suas páginas de status, adapte o brief acima informando os componentes e regiões que você usa, e dispare um alerta de teste para #vendor-status. O plano gratuito inclui 10 URLs com filtragem por IA, todos os canais de alerta e acesso via API, sem precisar de cartão de crédito. Comece a monitorar gratuitamente.

Julien, Gerente de Produto na Page Deltas