Que te avisen en Slack antes de que lo note un cliente, no después
La brecha entre “algo se rompió” y “alguien se enteró” es donde un incidente realmente se vuelve caro —no la falla en sí, el retraso antes de que una persona se entere. Una regla de notificación cierra esa brecha para la docena de eventos que de verdad justifican interrumpir a alguien.
Qué es realmente una regla
Un canal —un webhook entrante de Slack, cualquier URL de webhook que acepte un POST en JSON, o una dirección de correo— acotado a todas las apps del equipo o a una app específica, con una lista de qué eventos deben llegar a él. Cada equipo nuevo empieza con una regla ya configurada, no con una página de configuración vacía: un correo al propietario del equipo que cubre fallas de despliegue, servidores fuera de línea, crash loops y apps caídas, editable o eliminable como cualquier otra regla una vez que armes algo mejor para tu equipo.
La lista real de eventos
Las reglas de todo el equipo cubren falla/éxito de despliegue, un despliegue esperando aprobación, un servidor desconectándose, un crash loop, un servidor con poco disco/CPU/memoria, una app fallando sus comprobaciones de disponibilidad o un certificado cerca de vencer, nuevo desperdicio de costo o un pronóstico de presupuesto excedido (ligado a Costos y ahorros), una búsqueda de logs guardada que coincide demasiado seguido, un backlog de jobs acumulándose y vaciándose, una alerta de métrica activándose y resolviéndose, y ventanas de mantenimiento o jobs de datos de larga duración terminando.
Eso es la mayor parte de lo que un equipo chico tendría que armar por su cuenta en tres o cuatro herramientas separadas —las alertas propias de una página de estado, un SaaS de alertas de logs, una herramienta de anomalías de costo— como una sola lista en un solo lugar, con cada evento activable por separado según el canal.
Acotado a una sola app cuando es lo único que importa
Settings → General → Notifications en una app específica agrega una regla solo para ella —despliegue fallido/exitoso, app caída, crash loop, backlog de jobs, alertas de métricas, finalización de jobs de datos. Para un equipo que corre varias apps donde solo una es realmente crítica, esto es la diferencia entre un canal de notificaciones que la gente de verdad lee y uno que se silencia después de la tercera alerta irrelevante sobre un proyecto secundario.
Qué envía realmente una regla de webhook
Un POST en JSON real, no un aviso vago de “algo pasó” —el payload de una alerta de métrica lleva event: "metric_alert", status (firing o resolved), la metric, el value y el threshold que la disparó, y los eventos de despliegue incluyen la nota propia del despliegue. Suficiente estructura para enrutar hacia lo que un equipo ya use para on-call, sin tener que hacer scraping de un mensaje de Slack para entender qué pasó realmente.
Por separado, Team → Webhooks maneja webhooks salientes firmados, pensados para que tus propios sistemas los consuman de forma programática —un mecanismo distinto al de las reglas de notificación, que vale la pena distinguir porque los dos resuelven problemas cercanos pero distintos (avisar a una persona vs. integrar un sistema).
Lo que honestamente sigue en beta
La entrega de correo depende de que el envío de email esté configurado del lado propio de Railyard, y está marcada como beta exactamente por eso —cualquier cosa de la que de verdad dependas debería tener también una regla de Slack o webhook como segundo canal, no solo correo. Cada regla tiene un solo destino; dos canales de Slack significan dos reglas, no una regla con dos destinos. Ambos son límites chicos y específicos, dichos con claridad en vez de descubiertos el día en que una alerta por correo no llegó en silencio.
Referencia completa: Notificaciones.