Como te informamos ou alertamos
Uma interrupção só vale a pena ser detetada se a pessoa certa souber dela. Enviamos notificações para onde a tua equipa já está e para os teus próprios sistemas via webhooks.
Os canais
Cada canal recebe a mesma mensagem: qual monitor, desde quando e porquê. Abaixo encontras uma lista de canais disponíveis.
-
Email Cada plano
Uma mensagem para qualquer endereço. O endereço de e-mail precisa ser confirmado uma vez.
-
Webhook (POST) Cada plano
Um corpo JSON com os dados relevantes enviado para um URL que forneceste. Para a tua própria automação: abre um ticket, chama alguém, muda uma luz de estado.
-
Webhook (GET) Cada plano
Os mesmos campos do webhook POST, mas agora como parâmetros de consulta, para um receptor que aceita pedidos GET.
-
PagerDuty Starter e acima
Um incidente através da Events API v2, aberto numa interrupção e resolvido na recuperação, para que a escalada do PagerDuty trate do resto.
-
Slack Pro e Business
Uma mensagem num canal, vermelho para offline e verde para de volta online, através de um webhook.
-
Microsoft Teams Pro e Business
A mesma mensagem num canal do Teams, através de um webhook.
-
Discord Pro e Business
A mesma mensagem num canal do Discord, através de um webhook de canal.
-
Telegram Pro e Business
A mesma mensagem num chat, através do teu próprio bot.
Quem ouve sobre o quê, e quando
Confirmado em primeiro lugar
Nada é enviado com base na opinião de uma única sonda. Uma falha torna-se uma interrupção quando sondas em três continentes concordam, então um alerta significa que o site está offline e não apenas um problema de rede.
Regras e escalamento
Uma regra descreve quem recebe notificações sobre quais monitores e em que horário. Coloca a lista de plantão num grupo de contactos com um atraso por membro. Isto funciona como a tua política de escalada.
De volta online, dito uma vez
Todos os que foram informados sobre a falha são informados quando termina, com a duração que teve. Não te acordaremos para dizer que a falha acabou.
Testa antes de precisares
Cada endereço tem um botão que envia um teste pelo mesmo caminho que um alerta real segue, formulado para que não possa ser confundido com uma falha real.
O webhook, para os teus próprios sistemas
Um endereço de webhook é um URL teu. Chamamos quando uma falha é confirmada, quando recupera e quando carregas em testar. POST envia os campos como um corpo JSON; GET envia-os como parâmetros de consulta. O URL é armazenado encriptado e nunca mostrado na íntegra novamente, porque quem o tiver pode fazer POST para ele.
| Campo | O que contém |
|---|---|
| reason | down quando uma falha é confirmada, recovery quando termina, test quando alguém carregou no botão |
| monitor | O nome do monitor |
| monitor_id | O seu id |
| target | O que verifica: o URL, host ou nome |
| type | O tipo de verificação, como um nome curto como https, dns ou ssl_cert |
| cause | Por que falhou, em poucas palavras, quando sabemos |
| error_class | A mesma coisa como um nome curto que um programa pode usar, como timeout, connection ou certificate_expired |
| started | Quando a interrupção começou |
| confirmed_at | Quando a falha foi confirmada |
| confirmed_from | Os continentes que a confirmaram, como uma lista de nomes. |
| degraded | true quando o monitor está lento ou a perder pacotes em vez de offline |
| resolved | Quando terminou, como um timestamp ISO 8601, numa recuperação |
| duration | Quanto tempo durou, em palavras, numa recuperação |
| incident_id | O id do incidente, o mesmo na falha e na sua recuperação |
Um campo sem valor é null no JSON e omitido num GET. Tens de responder com qualquer estado abaixo de 400. Qualquer outro conta como uma entrega falhada e é tentado novamente após 30 segundos, 2 minutos e 10 minutos, depois desistimos: um alerta que não chegou dentro de um quarto de hora é história, não notícia.