Um alerta que não significa nada é pior do que nenhum.
A parte difícil da monitorização não é detectar que um servidor não responde. É decidir se aquilo que aconteceu merece acordar alguém.
Detectar que um servidor não responde é, tecnicamente, trivial. Um pedido HTTP a cada minuto e uma condição. Não é aí que está a dificuldade.
A dificuldade é que a rede falha sozinha. Um pedido perdido, um pico de latência de três segundos, um reinício do balanceador do alojamento. Nenhuma dessas coisas é uma falha do site, e todas produzem exactamente a mesma resposta que uma falha do site produziria.
O custo de tratar as duas da mesma maneira não é o telemóvel a tocar às três da manhã. É o que acontece a seguir: ao terceiro alerta falso, a pessoa deixa de olhar. E quando o quarto for a sério, também não vai ser lido.
// como vai funcionar
O que a De Olho vai fazer com isto.
Está tudo no futuro porque é aí que está: a De Olho abre em 2026. Nada nesta página dá para usar hoje.
-
A primeira falha não avisa ninguém
Marca o site como suspeito e nada mais. É este passo que quase todas as ferramentas simples saltam, e é a razão de os alertas delas deixarem de ser lidos.
-
Segunda tentativa, poucos segundos depois
Não esperamos pelo ciclo seguinte de um minuto — repetimos logo. Se responder, foi um soluço e ninguém precisa de saber. Se falhar outra vez, o alerta dispara.
-
Preferimos avisar tarde a avisar mal
Esta confirmação acrescenta alguns segundos ao aviso. É uma troca deliberada: trinta segundos de atraso custam pouco, um alerta que ninguém já lê custa tudo.
-
O aviso de recuperação fecha o assunto
Quando o site volta, recebes a confirmação com a duração exacta da falha. É a mensagem que consegues reencaminhar ao cliente sem ter de escrever nada.
// limites
E o que isto não vai fazer.
Dizê-lo agora poupa-te tempo se o que precisas for outra coisa.
- A confirmação não elimina falsos positivos, só os torna raros. Uma rota partida durante dois minutos vai gerar um alerta legítimo do nosso ponto de vista e nenhum problema do ponto de vista dos teus visitantes.
- Enquanto tivermos um só ponto de verificação, não conseguimos distinguir "o site caiu" de "a rota entre nós e o site caiu". Dizemos de onde verificamos precisamente para essa dúvida ser tua também.
- Não vamos ter escalonamento de serviço nem chamadas telefónicas no lançamento. Isto é uma ferramenta de aviso e não uma ferramenta de plantão.
// perguntas
O que nos perguntam sobre isto.
Quanto tempo demora o alerta a chegar?
Segundos depois da confirmação, que por sua vez acontece poucos segundos depois da primeira falha. Não damos um número exacto porque depende do canal — um webhook chega antes de um email, e nenhum dos dois depende só de nós.
Vão avisar por cada verificação falhada?
Não. Uma falha contínua é um incidente e um incidente gera um aviso quando começa e outro quando acaba. Repetir a mesma má notícia de minuto a minuto é a forma mais rápida de te fazer silenciar o canal.
E um site que oscila entre online e offline?
É o caso mais chato e não temos ainda uma resposta fechada. A intenção é agrupar as oscilações num só incidente em vez de disparar dezenas de avisos — quando estiver decidido, ficará escrito aqui.
// a seguir
Isto não funciona sozinho.
Cada uma destas depende das outras — uma verificação rápida sem confirmação é ruído, e um alerta sem histórico não responde a ninguém.
-
Verificação ao minuto
Um pedido HTTP todos os minutos, em vez dos cinco em cinco das ferramentas gratuitas.
-
Alertas nos canais que já usas
Email, Slack, Discord e webhook. Todos os canais em todos os planos, sem taxa por canal.
-
Verificação a partir de Portugal
Um servidor em Portugal a fazer o pedido — a mesma rota que os teus visitantes fazem.
Avisamos-te quando abrirmos.
Um email quando o produto estiver pronto, com acesso antecipado e o preço de lançamento. Entretanto, o "Está em baixo, ou és só tu?" já funciona e não pede conta.