Alertas que pode auditar

Canais

• E-mail — o que aconteceu, desde quando, que regiões de sondagem o confirmaram, e um link direto para a verificação.
• Telegram — através de um bot que o okokumo mantém, pelo que a configuração é premir Ligar e depois Start, em vez de registar um bot próprio.
• Slack — um incoming webhook que cola, entregue como blocos formatados, com um envio de teste a partir da interface.
• Discord — um incoming webhook que cria no seu próprio servidor (Canal → Editar canal → Integrações → Webhooks) e cola da mesma forma. Os alertas chegam como embed — vermelho em baixo, verde na recuperação, cinzento em pausa — com a mudança de estado, a hora, o motivo e o alvo, e o título liga de volta à verificação. Nada para instalar e nenhum bot para convidar.
• Webhook — JSON assinado sobre HTTPS para qualquer endpoint, repetido com backoff e com payload documentado. Cada entrega leva uma assinatura HMAC para que quem a recebe possa verificar que veio de nós.

Não há SMS nem chamadas telefónicas. Ambos estão na lista do que este produto não faz.

Um canal não recebe nada até ser confirmado

Adicionar um canal são dois passos, não um. O e-mail valida quando clica no link enviado para esse endereço; o webhook, o Slack e o Discord validam no momento em que uma entrega de teste funciona. Até então o canal existe mas está pendente, e canais pendentes não recebem nada.

É deliberado, e vale a pena compreender em vez de contornar: garante que um alerta nunca vai para um destino que ninguém confirmou — um endereço com um erro de escrita, um webhook que nunca esteve acessível, um canal de Slack que foi apagado. O preço é que uma verificação pode falhar sem o alertar se o seu único canal nunca foi confirmado, e é exatamente por isso que o registo de entregas abaixo existe e o diz.

Encaminhamento

Os canais podem ser ligados a verificações específicas, ou deixados como predefinição da organização que cobre tudo. Assim, a API virada para o cliente pode acordar um telefone por Telegram enquanto uma tarefa noturna em lote escreve numa sala de Slack que ninguém vê às 3 da manhã.

Um incidente, um alerta

Uma transição para em baixo envia uma vez. Enquanto o estado não muda, nada volta a notificar — um serviço em baixo durante seis horas não produz seis horas de mensagens, porque um canal que dá falsos alarmes é silenciado, e um canal silenciado é pior do que não ter monitorização. A recuperação envia a sua própria notificação, para que o silêncio nunca tenha de ser interpretado.

Por baixo disto, uma falha tem de ser confirmada por uma segunda região de sondagem da UE independente antes de qualquer coisa começar. Como funciona →

A parte que ninguém mais lhe mostra

app.okokumo.com/checks/api

Cada verificação mantém um registo de entregas: o que foi enviado, para que canal, quando — e o que foi ignorado, com o motivo. Desduplicado porque o estado não tinha mudado. Ignorado porque o canal ainda estava pendente. Falhado porque o endpoint devolveu um 500.

Todos os produtos de monitorização afirmam que o alertam. Esta é a afirmação que se pode verificar, e a razão pela qual o registo é uma funcionalidade e não uma tabela interna.

Através da API

Os alertas de uma verificação são legíveis através da API REST versionada com uma chave da organização, ao lado de verificações, estados e resultados. Documentação →