Alertas de servidor por email con Nylas CLI (sin SMTP)
Nylas CLI te deja mandar alertas de servidor por email CLI desde cualquier máquina con un solo binario, sin montar un servidor de correo ni pelearte con SMTP. Sirve para fallos de cron, reportes de backup y avisos de deploy. El envío real lo hace la API de Nylas, así que la casilla es tuya y queda con histórico buscable.
Nylas CLI es una herramienta de línea de comandos que envía correos a través de la API de Nylas usando un único ejecutable. La instalás en un servidor, autenticás con tus credenciales de Nylas y disparás emails desde scripts de cron o despliegues, sin Postfix, sin relay propio y sin tener que administrar infraestructura de correo en cada caja. Es el envío de mail reducido a un comando.
En 30 segundos
- Qué resuelve: mandar mail desde un servidor sin configurar Postfix ni relay SMTP, con un solo binario.
- Para qué tipo de alertas: fallos de cron, reportes de backup, umbrales superados, resúmenes de deploy y auditorías nocturnas.
- Doble interfaz: el artículo de Nylas (publicado el 25 de junio de 2026) muestra cada operación en CLI y en llamada HTTP, porque tus scripts usan la CLI y tus servicios pegan a la API.
- Qué NO es: no es un pager. Para despertar a alguien a las 3am con escalado, eso sigue siendo trabajo de PagerDuty.
- Ventaja lateral: cada alerta queda como email buscable en una casilla que controlás vos.
¿Por qué fallan los webhooks y SMTP para alertas de servidor?
Casi todo el mundo arranca igual. Tirás un webhook de Slack desde un health-check, o apuntás tu monitoreo SaaS a un relay SMTP, y listo.
El problema aparece cuando lo que se rompe es justo lo que tenía que avisarte. La caja que no llega a internet no puede mandar nada a Slack. Las credenciales del relay vencen y, como advierte el artículo de Nylas, cada alerta de cron desaparece en silencio durante un mes antes de que alguien lo note (spoiler: siempre te enterás tarde).
Y después está el escenario clásico. Estás en una VM pelada, un nodo de build aire-gapped o la caja on-prem de un cliente, y el “solo instalá Postfix y configurá SPF” convierte una tarea de cinco minutos en una tarde entera. ¿Cuántas veces eso terminó bien a la primera? Casi ninguna. Esto se conecta con lo que analizamos en integrar notificaciones en tus pipelines.
¿Qué es Nylas CLI y cómo manda los emails?
La idea es simple: una casilla real, que es tuya, desde la que cualquier máquina con un solo binario puede enviar, sin servidor de correo que mantener. El binario no abre conexiones SMTP ni necesita un MTA local. Le pasás el mensaje y él pega contra la API de Nylas, que se encarga de la entrega.
Eso cambia el punto de falla. En vez de depender de que tu caja tenga Postfix bien configurado, SPF alineado y un relay con credenciales vigentes, dependés de una llamada HTTPS saliente. El autor (que trabaja en Nylas CLI, así que muestra los comandos exactos que usa él) lo plantea de los dos lados: la CLI para los scripts, la API para los servicios.
¿Cuáles son los casos de uso de las alertas por email?
Hay una banda enorme de alertas que importan, pero que no son críticas al segundo. Ahí es donde el email gana.
- Fallos de cron: el job nocturno se cae y querés saberlo a la mañana, no enterarte recién cuando falta el reporte.
- Reportes de backup: “backup completado, 4.2 GB, 02:14” como confirmación diaria que podés buscar después.
- Umbrales superados: disco al 90%, cola de mensajes pasada de tamaño, certificado por vencer.
- Resúmenes de deploy: qué se desplegó, qué versión, quién lo disparó.
- Auditorías nocturnas: el digest de seguridad o de cuentas que revisás con el café.
El denominador común: son importantes para aterrizar en una casilla y quedar con histórico buscable, pero ninguna justifica un teléfono sonando de madrugada. Te puede servir nuestra cobertura de alertas en tu plataforma de integración.
¿Cómo se instala y se arman los primeros comandos?
El flujo, según el artículo, es bajar el binario, autenticarte con tus credenciales de Nylas y mandar el primer mensaje. La CLI expone la operación de envío (el comando del tipo nylas message send) y la misma acción existe como llamada HTTP para cuando un servicio prefiere pegar directo a la API.
El detalle práctico: en una caja sin internet de salida no vas a poder usar esto, porque el binario igual necesita alcanzar la API de Nylas. Donde sí brilla es en el servidor que tiene salida HTTPS pero al que no le querés montar un stack de correo entero solo para mandar dos mails por día.
Ejemplo: avisar cuando un cron se cae
El patrón básico es capturar el exit code y, si no es cero, mandar el mail. Algo así (los flags exactos los confirmás en la doc de Nylas):
#!/bin/bash
/opt/jobs/backup.sh
if [ $? -ne 0 ]; then
nylas message send \
--to [email protected] \
--subject "FALLO: backup nocturno en $(hostname)" \
--body "El job terminó con error a las $(date)."
fiEjemplo: confirmar un deploy
El resumen de deploy es el caso más agradecido, porque convierte cada despliegue en un email archivable. Le metés la versión, el host y el horario, y al toque tenés una línea de tiempo buscable en la casilla sin tocar ninguna herramienta extra. Lo explicamos a fondo en herramientas CLI sin dependencias externas.
Email vs webhooks vs PagerDuty: ¿cuándo usar cada uno?
El propio autor pone la advertencia honesta arriba de todo: el email no es un pager. Si necesitás avisos sub-minuto, con escalado por rotación y despertar a alguien, eso es PagerDuty y no hay vuelta. El email se queda con la banda del medio.
| Criterio | Email (Nylas CLI) | Webhook (Slack) | PagerDuty |
|---|---|---|---|
| Urgencia | Media (horas) | Media (minutos) | Crítica (segundos) |
| Histórico buscable | Sí, en la casilla | Limitado al canal | Sí, con incidentes |
| Escalado automático | No | No | Sí |
| Funciona sin servidor de correo | Sí | Sí | Sí |
| Punto débil | Nadie mira el inbox a las 3am | Si no hay internet, no avisa | Costo y complejidad |
| Ideal para | Cron, backups, digests | Avisos de equipo en vivo | Incidentes que despiertan |
Lo interesante es que no compiten tanto como parece. Mandás los digests y reportes por email, los avisos de equipo en vivo por webhook, y reservás el pager para lo que de verdad no puede esperar.
¿Cuáles son las limitaciones?
El email alerting depende de un humano que abra la casilla. No escala solo, no insiste, no llama por teléfono. Si nadie revisa el inbox, la alerta más urgente queda ahí sentada mirándote.
La contracara, y la razón por la que el autor lo defiende, es ese histórico buscable: cada alerta queda como email, con fecha, asunto y cuerpo, listo para filtrar dentro de seis meses cuando quieras reconstruir qué pasó. Esa “memoria” gratis es lo que un webhook efímero no te da. Ya lo cubrimos antes en proteger alertas en desarrollo.
Errores comunes al armar alertas por email
- Tratar el email como pager: si tu alerta necesita reacción en segundos, el mail no es el canal. Mandá lo crítico a un sistema de paging y dejá la casilla para lo demás.
- No probar el envío al instalar: mandá un mail de prueba apenas configurás. El clásico es asumir que funciona y descubrir un mes después que ninguna alerta salió.
- Depender de una caja sin internet: la CLI necesita alcanzar la API de Nylas. En un nodo aire-gapped sin salida HTTPS, esto no va a andar, así que verificá la conectividad antes.
- Asuntos genéricos: meté el hostname y el resultado en el subject (“FALLO: backup en web-03”). Si todos los mails dicen lo mismo, no podés filtrar nada después.
Un apunte de infraestructura: si estás levantando estas alertas sobre un VPS o un servidor donde corren tus jobs, asegurate de que el hosting te dé salida HTTPS estable. Para infraestructura en Argentina, donweb.com es una opción para alojar esos servidores con soporte local.
Preguntas Frecuentes
¿Cómo enviar alertas de servidor por email sin configurar SMTP?
Con Nylas CLI mandás el mail con un solo binario que pega contra la API de Nylas, sin montar Postfix ni configurar un relay SMTP. Instalás la herramienta, autenticás con tus credenciales y disparás el envío desde un script. La caja solo necesita salida HTTPS hacia la API.
¿Qué es Nylas CLI y para qué sirve en DevOps?
Nylas CLI es una herramienta de línea de comandos que envía emails a través de la API de Nylas con un único ejecutable. En DevOps sirve para alertas de cron, reportes de backup, avisos de umbrales y resúmenes de deploy, sin administrar infraestructura de correo en cada servidor.
¿Por qué fallan los webhooks para alertas de servidor?
Los webhooks fallan cuando la máquina que tiene que avisar no llega a internet o cuando justo se rompe lo que sostenía la notificación. Una caja aislada no puede pegarle a un webhook de Slack, así que la alerta nunca sale y el problema queda invisible.
¿Sirve para reportes de cron y backup?
Sí, esos son sus casos ideales. Capturás el exit code del job y mandás un mail con el resultado, la fecha y el tamaño del backup. Cada reporte queda como email buscable, lo que te arma un histórico para revisar cuándo empezó a fallar algo.
¿Reemplaza a PagerDuty?
No. El email no hace escalado automático ni despierta a nadie a las 3am, y el propio autor lo aclara. Para incidentes críticos con rotación seguís necesitando un pager. Nylas CLI cubre la banda del medio: alertas importantes que pueden esperar a que alguien abra la casilla.
Conclusión
Lo que cambia acá no es la tecnología de mail, es el punto de falla. En vez de mantener Postfix, SPF y credenciales de relay en cada servidor, mandás las alertas con un binario que solo necesita salida HTTPS. Eso te saca de encima toda una categoría de fallos silenciosos en cron, backups y deploys.
El movimiento concreto: identificá qué alertas tuyas son de la banda del medio (importantes pero no de segundos), pasalas a email con histórico buscable, y dejá el paging crítico donde tiene que estar. Probá el envío el día que lo instalás, no el mes que viene cuando ya sea tarde.
