Monitoramento de sites: webhooks
A Uptimia verifica os seus sites, certificados e fluxos de checkout a partir do exterior da sua rede e chama o seu endpoint sempre que uma falha é confirmada. O seu próprio código decide o que acontece a seguir — abrir um chamado de suporte, reiniciar um serviço, alimentar um dashboard — e todas as verificações enviam o mesmo formato, para que escreva o handler uma única vez.
Authorization: Bearer •••••••••••••••• Content-Type: application/json { "id": 3517, "monitor_type": "uptime", "monitor_name": "Checkout — caldmont.com", "monitor_unique_id": "checkout-prod", "monitor_status": "down", "severity": "critical", "incident_start_time": "2026-07-30T11:47:12+02:00", "incident_end_time": "", "incident_duration_seconds": 0, "message": "*ALERT*: Project Checkout — caldmont.com is DOWN", "monitor_notes": "Failover: drain eu-west-2 first" }
Não é mensagem, é contrato
Todos os outros canais terminam numa pessoa, e as pessoas são leitoras tolerantes. O código não é — por isso a parte interessante nunca é a carga útil, mas sim as garantias por trás dela.
“Algo quebrou” — descubra o resto sozinho
A redação pode variar entre versões porque o leitor se adapta. No momento em que um sistema passa a depender dela, essa informalidade transforma-se numa falha na sua integração.
Onze campos, cinco novas tentativas, uma estrutura
Um objeto para cada tipo de verificação: escreva um handler, ramifique em dois campos. É tentado novamente cinco vezes antes de ser descartado, pelo que são possíveis duplicados — documentados em vez de descobertos.
O alerta chega ao seu próprio código
Uma verificação falha e a Uptimia chama o seu endpoint com os detalhes, já confirmados. A sua própria automação decide o que acontece a seguir — aqui, um chamado de suporte que se abre sozinho e se fecha na recuperação.
Ligue um webhook em três passos
Não há aplicação para autorizar nem biblioteca para instalar — a Uptimia só precisa de um URL a chamar e, se o endpoint estiver protegido, de um cabeçalho que a deixe entrar.
Cole o URL do seu endpoint
É todo o registro — um único URL público.
Adicione seus cabeçalhos de autenticação
Opcional — cabeçalhos enviados exatamente como os escreve, para que um token deixe a Uptimia entrar pela sua própria porta.
Aponte os seus monitores para ele
Escolha as verificações que o devem chamar, e uma entrega de teste comprova a conexão com o formato real.
Registrar um endpoint de webhook
O Centro de ajuda cobre a implementação: adicionar o URL, escrever os cabeçalhos personalizados, enviar um POST de teste, e interpretar o que uma entrega falhada está lhe dizendo.
Todos os tipos de verificação. Uma estrutura.
Um certificado expirando, um cron job que nunca reportou e um servidor acima do limiar de CPU chegam todos como o mesmo objeto simples. Dois campos distinguem-nos.
Pontes de chat, linhas de base de dados, ações automáticas
Assim que um incidente é um objeto que o seu código aceitou, as aplicações úteis deixam de se parecer com alertas.
Os outros canais avisam uma pessoa.Este avisa o seu código.
A plataforma completa no período de teste — todos os tipos de verificação, mais de 171 sondas, e cada incidente confirmado entregue como um objeto que lhe pertence.
As garantias de entrega, por escrito
Ninguém consegue escrever um handler fiável com base em “vamos enviar-lhe uma notificação”. Estas são as garantias reais.
Pelo menos uma vez, com cinco novas tentativas
Dez segundos para responder, e qualquer 2xx conta como aceito. Tudo o resto volta à fila e é repetido cinco vezes, cada espera um minuto mais longa do que a anterior, e depois é descartado — por isso responda primeiro e faça o trabalho a seguir.
Um objeto simples, onze chaves
Sem aninhamento, sem invólucro, sem esquema que muda consoante o tipo de verificação. Dois campos distinguem; os outros nove nunca mudam de significado — incluindo monitor_notes, a linha do runbook que quem configurou o monitor deixou escrita.
Uma tempestade acrescenta uma chave
Monitores que falham em conjunto tornam-se uma única requisição com um objeto de grupo adicional — membros, contagens, confirmação. Os handlers que o ignoram continuam funcionando.
Os seus cabeçalhos, repassados
Enviados exatamente como escritos, para que um bearer token ou um segredo compartilhado funcione. Não há assinatura do corpo — verifique o cabeçalho do lado do servidor e mantenha o URL em segredo.
Onde se recusará a publicar
Apenas http(s) público; loopback e intervalos privados são rejeitados. O endereço é resolvido uma única vez e fixado, os redirecionamentos são ignorados, o TLS é verificado.
Sem link de confirmação — de propósito
Os canais que uma pessoa lê trazem um link assinado que interrompe a cadeia. As máquinas recebem os fatos e nada mais — um pipeline de registros que consegue silenciar um alerta acabará por fazê-lo.
Como funcionam os webhooks de monitoramento
A Uptimia verifica os seus sites a partir de mais de 171 localizações externas e, quando uma verificação falha, envia um POST HTTP com um corpo JSON para qualquer URL que registre. O mesmo objeto simples chega para cada tipo de verificação — qual o monitor, o que aconteceu, quando, e durante quanto tempo — para que um único handler cubra todos eles, e as entregas falhadas são repetidas.
O erro que todo mundo comete no primeiro dia
Recuperações, alertas e testes compartilham um único endpoint. monitor_status é down, up ou test; severity é critical ou trouble, e vazio numa recuperação. Ramifique com base nos dois.
Confirmado antes de o seu código saber
A automação só é tão fiável quanto o seu gatilho. Uma verificação web nunca é alertada com base na opinião de uma única sonda — uma falha suspeita é testada de novo a partir de outras sondas primeiro.
Onze campos, todos os eventos
O que está sempre presente, e o que contém.
Veja todos os canais de alertas →| Campo | Exemplo | O que contém |
|---|---|---|
| id | 4172 | O id numérico do monitor na Uptimia |
| monitor_type | uptime | Que tipo de verificação foi acionada |
| monitor_name | Dispatch API | O nome que lhe deu (nome do site para verificações de disponibilidade) |
| monitor_unique_id | dispatch-api-eu | O seu próprio identificador — a chave de junção |
| monitor_status | down | down, up ou test |
| severity | critical | critical ou trouble — vazio numa recuperação |
| incident_start_time | 2026-07-24T02:17:04+02:00 | ISO 8601, fuso horário da conta |
| incident_end_time | 2026-07-24T02:31:07+02:00 | Vazio enquanto o incidente está aberto |
| incident_duration_seconds | 843 | Zero até o incidente se fechar |
| message | *ALERT*: Project … is DOWN | O resumo de uma linha que os outros canais recebem |
| monitor_notes | Failover: drain eu-west-2 first | A nota do monitor — vazia quando ninguém escreveu nenhuma |
Perguntas frequentes sobre webhooks personalizados
01O que é enviado exatamente?+
02Como autentico a requisição?+
03O que acontece se o meu endpoint estiver lento ou indisponível?+
04Vou alguma vez receber o mesmo evento duas vezes?+
05Posso apontá-lo para o localhost ou para um endereço interno?+
06Seguem redirecionamentos?+
07O que chega quando vários monitores falham ao mesmo tempo?+
08O meu handler pode confirmar ou responder?+
09O que é que o “Enviar teste” publica, na prática?+
10Quantos endpoints posso ter, e está incluído?+
Um URL, cada incidente confirmado
Registre um endpoint, associe-o aos monitores que importam, e cada falha confirmada chega como um objeto que os seus sistemas podem arquivar e usar para agir.