Sendo avisado no Slack antes do cliente notar, não depois
A distância entre “algo quebrou” e “alguém ficou sabendo” é onde um incidente de fato fica caro — não a falha em si, o atraso antes de um humano saber dela. Uma regra de notificação fecha essa distância para a dúzia ou mais de eventos que de fato justificam interromper alguém.
O que uma regra realmente é
Um canal — um webhook de entrada do Slack, qualquer URL de webhook que aceite um POST em JSON, ou um endereço de e-mail — com escopo para todos os apps da equipe ou um app específico, com uma lista de marcação de quais eventos devem chegar até ele. Toda equipe nova começa com uma regra já configurada, não uma página de configurações vazia: um e-mail para o dono da equipe cobrindo falhas de deploy, servidores offline, crash loops e apps fora do ar, editável ou removível como qualquer outra regra depois que você configurar algo mais adequado para a sua equipe.
A lista real de eventos
Regras para a equipe inteira cobrem falha/sucesso de deploy, um deploy esperando aprovação, um servidor caindo, um crash loop, um servidor ficando com pouco disco/CPU/memória, um app falhando nas verificações de uptime ou um certificado perto de expirar, novo desperdício de custo ou uma previsão de orçamento sendo excedida (ligado a Costs and savings), uma busca de log salva disparando com muita frequência, uma fila de jobs se acumulando e esvaziando, um alerta de métrica disparando e se resolvendo, e janelas de manutenção ou jobs de dados de longa duração terminando.
Isso é a maior parte do que uma equipe pequena de outra forma teria que ligar em três ou quatro ferramentas separadas — o próprio sistema de alerta de uma status page, um SaaS de alerta de log, uma ferramenta de anomalia de custo — como uma lista só, num lugar só, cada evento ativável de forma independente por canal.
Com escopo para um app quando é só isso que importa
Settings → General → Notifications num app específico adiciona uma regra só para ele — deploy falhou/teve sucesso, app fora do ar, crash loop, fila de jobs, alertas de métrica, conclusões de job de dados. Para uma equipe rodando vários apps onde só um é de fato crítico, essa é a diferença entre um canal de notificação que as pessoas de fato leem e um que é silenciado depois do terceiro alerta irrelevante sobre um projeto paralelo.
O que uma regra de webhook de fato envia
Um POST em JSON real, não um ping vago de “algo aconteceu” — o payload de um alerta de métrica carrega event: "metric_alert", status (firing ou resolved), a metric, o value e o threshold que dispararam, e eventos de deploy incluem a própria nota do deploy. Estrutura suficiente para rotear para o que quer que uma equipe já use para plantão, sem precisar raspar uma mensagem do Slack para descobrir o que de fato aconteceu.
Separadamente, Team → Webhooks cuida de webhooks de saída assinados, feitos para os seus próprios sistemas consumirem de forma programática — um mecanismo diferente das regras de notificação, vale saber a diferença já que os dois resolvem problemas adjacentes mas distintos (avisar um humano vs. integrar um sistema).
O que honestamente ainda está em beta
A entrega de e-mail depende do envio de e-mail estar configurado do lado do próprio Railyard, e está marcada como beta exatamente por isso — qualquer coisa de que você de fato dependa também deveria ter uma regra de Slack ou webhook como segundo canal, não só e-mail. Cada regra tem um destino; dois canais do Slack significam duas regras, não uma regra com dois alvos. Os dois são limites pequenos e específicos, declarados claramente em vez de descobertos no dia em que um alerta por e-mail silenciosamente não chegou.
Referência completa: Notifications.