Índice
- La línea
- Envía también el código de salida
- Conviértelo en una función de shell
- Llámame solo cuando falle
- Sobrevivir a un portátil cerrado y a una sesión SSH caída
- Agentes de código IA
- Qué no poner en la notificación
- Preguntas frecuentes
- ¿Por qué no usar terminal-notifier o notify-send?
- ¿Funciona en Windows?
- ¿Puedo recibirlo en el reloj?
- ¿Y si el comando tarda 12 horas?
- ¿Pueden recibirlo mis compañeros?
- Cierre
- Contenido relacionado
Lanzas un entrenamiento, una batería de tests completa, un docker build o un agente de código trabajando en una tarea larga. Y te quedan dos malas opciones: sentarte a mirar una barra de progreso, o marcharte y volver veinte minutos después para descubrir que falló a los noventa segundos.
Hay una tercera opción y ocupa una línea.
La línea
Crea un canal en Echobell, copia su URL de webhook y añade esto detrás de lo que estés ejecutando:
pnpm build; curl -sS -X POST https://hook.echobell.one/t/TU_TOKEN \
-H 'content-type: application/json' \
-d '{"title":"compilación terminada","body":"echobell-web"}'
Fíjate en el ; y no en &&. Con && la notificación solo se dispara si el comando tuvo éxito, que es justo al revés: el fallo es el caso del que más quieres enterarte.
Envía también el código de salida
Una notificación que dice "terminado" cuenta media historia. Captura el estado:
pnpm build; s=$?; curl -sS -X POST https://hook.echobell.one/t/TU_TOKEN \
-H 'content-type: application/json' \
-d "{\"title\":\"compilación $([ $s -eq 0 ] && echo ok || echo FALLÓ)\",\"status\":\"$s\"}"
s=$? tiene que ir inmediatamente después del comando: cualquier cosa en medio, incluida la propia prueba [, sobrescribe $?.
Conviértelo en una función de shell
Escribir eso cada vez anula la ventaja. Pon esto en ~/.zshrc o ~/.bashrc:
notify() {
"$@"
local status=$?
curl -sS -X POST "$ECHOBELL_HOOK" \
-H 'content-type: application/json' \
-d "{\"command\":\"$*\",\"status\":\"$status\",\"host\":\"$(hostname -s)\"}" \
>/dev/null
return $status
}
Define ECHOBELL_HOOK en el perfil de tu shell —o mejor, mantenlo fuera de tu repositorio de dotfiles y expórtalo desde un archivo que no versiones—. Después:
notify pnpm test
notify cargo build --release
notify python train.py
El return $status del final importa: mantiene notify transparente, así que notify make && ./deploy.sh sigue comportándose como esperas.
Con ese payload, las plantillas del canal pueden ser:
Título
{{command}} · {{status}}
Cuerpo
en {{host}}
Llámame solo cuando falle
La mayoría de ejecuciones salen bien y no necesitas enterarte. Dos canales lo resuelven limpiamente: uno normal para todo y otro de llamada con una condición:
status != "0"
Apunta notify al segundo canal para aquello por lo que te levantarías de la cama, y las ejecuciones correctas se quedan en silencio.
Sobrevivir a un portátil cerrado y a una sesión SSH caída
Si el comando corre por SSH, cerrar el portátil mata el shell y la notificación nunca se envía. Dos arreglos:
tmux — arranca el comando dentro de una sesión y desconéctate:
tmux new -d -s build 'notify pnpm build'
nohup — para algo puntual:
nohup bash -c 'notify pnpm build' >/dev/null 2>&1 &
En ambos casos el proceso sobrevive a tu conexión y la notificación llega estés o no conectado.
Agentes de código IA
El mismo patrón cubre a un agente de CLI trabajando en una tarea larga:
notify codex exec "refactoriza el módulo de pagos y ejecuta los tests"
Para agentes que se detienen a mitad de camino esperando a una persona —una aprobación, una petición de permiso— una notificación de finalización es la herramienta equivocada, porque la ejecución no ha terminado. Ese caso necesita el hook o el callback del propio agente, y merece una llamada más que un push. Convertir las aprobaciones de un agente en llamadas telefónicas cubre eso, incluido el hook Notification de Claude Code y su matcher agent_needs_input.
Usa los dos: el hook para "estoy atascado", la función de shell para "he terminado".
Qué no poner en la notificación
La salida del comando, no. Es tentador meter las últimas líneas de una compilación fallida en el cuerpo. Resístete: los logs de compilación contienen tokens, cadenas de conexión y datos de clientes más a menudo de lo que se cree, y el cuerpo de una notificación acaba en una pantalla de bloqueo. Envía el código de salida y ve a mirar la terminal.
La URL del canal, tampoco, en un repositorio de dotfiles público. Cualquiera con la URL puede publicar en tu canal. Guárdala en un archivo sin versionar y activa Solo POST para que una vista previa de enlace no la dispare.
Preguntas frecuentes
¿Por qué no usar terminal-notifier o notify-send?
Esos muestran una notificación en la máquina que ejecuta el comando. Sirven mientras estás delante. El sentido de este montaje es el caso en que no lo estás: una máquina remota, un portátil cerrado, otra habitación.
¿Funciona en Windows?
El patrón sí; la sintaxis cambia. En PowerShell el equivalente es Invoke-RestMethod -Method Post -Uri $env:ECHOBELL_HOOK -ContentType application/json -Body $json, con $LASTEXITCODE en lugar de $?.
¿Puedo recibirlo en el reloj?
Sí. Las suscripciones llegan a un Apple Watch emparejado, que es sinceramente el formato adecuado para "la compilación ha terminado".
¿Y si el comando tarda 12 horas?
Nada en este montaje caduca: el curl se ejecuta cuando el comando retorna. Lánzalo bajo tmux para que una caída de conexión no se lleve el proceso.
¿Pueden recibirlo mis compañeros?
Sí. Comparte el canal y cada suscriptor elige su tipo de notificación. Útil en una máquina de entrenamiento compartida donde a más de uno le importa que la GPU vuelva a estar libre.
Cierre
Una función de shell, un canal y una condición si solo quieres los fallos. Cuesta unos dos minutos montarlo y te devuelve los veinte que pasas mirando barras de progreso.
Descarga Echobell para iPhone o consíguelo en Google Play, y pruébalo con algo que tarde lo bastante como para irte.