Um alerta avisa quando seus workflows se comportam de um jeito que você quer saber: falhas repetidas, uma execução lenta, uma execução cara ou nenhuma atividade. Você configura um alerta uma vez no workspace, escolhe a condição que dispara e define como quer ser avisado.
Regras de alerta
Uma regra de alerta é a condição que dispara o alerta. Cada alerta tem uma regra, configurada com seus próprios limiares.
| Regra | Dispara quando | Configurações principais |
|---|---|---|
| Consecutive failures | as últimas N execuções falharam | contagem (1 a 100, padrão 3) |
| Failure rate | a taxa de erro em uma janela passa de um limiar | percent (1 a 100), horas da janela (1 a 168) |
| Error count | o número de erros em uma janela passa de um limiar | contagem (1 a 1000), horas da janela |
| Latency threshold | uma execução demora mais que um tempo fixo | duração em ms (1s a 1h, padrão 30s) |
| Latency spike | uma execução está bem mais lenta que a média recente | percent mais lento (10 a 1000), horas da janela |
| Cost threshold | uma única execução custa mais que um valor definido | dólares (0,01 a 1000, padrão $1) |
| No activity | nenhuma execução acontece em uma janela | horas (1 a 168, padrão 24) |
As regras baseadas em taxa (failure rate, latency spike) precisam de pelo menos 5 execuções na janela antes de avaliar. No-activity é checado por um poll em background, não a cada execução. Depois que um alerta dispara, ele fica quieto por 1 hora para um único problema não te inundar.
Você pode restringir uma regra a todos os workflows ou a workflows específicos, e filtrar por nível (info ou error) e por tipo de trigger.
Canais de entrega
Um alerta pode chegar de três formas:
- Webhook envia um payload JSON assinado para uma URL que você fornece.
- Email envia para uma lista de destinatários, até 10.
- Slack publica em um canal por meio de uma conta Slack conectada.
Payload do webhook
Um alerta por webhook é um HTTP POST com corpo JSON:
{
"id": "evt_...",
"type": "workflow.execution.completed",
"timestamp": 1719907200000,
"data": {
"workflowId": "wf_...",
"workflowName": "Lead scorer",
"executionId": "exec_...",
"status": "error",
"level": "error",
"trigger": "api",
"startedAt": "2026-06-01T12:00:00.000Z",
"endedAt": "2026-06-01T12:00:01.200Z",
"totalDurationMs": 1200,
"cost": { "total": 0.0042 }
}
}Você também pode incluir o finalOutput da execução, os traceSpans (só webhook), status de rate-limit e dados de uso ativando essas opções no alerta.
Verificando um webhook
Cada entrega é assinada para você confirmar que veio do Zoen. A assinatura fica no header sim-signature:
sim-signature: t=1719907200000,v1=<hex>Para verificar, calcule um HMAC-SHA256 sobre {t}.{raw_body} com o segredo do webhook e compare o resultado com v1:
import { createHmac } from 'node:crypto'
function verify(rawBody, signatureHeader, secret) {
const parts = Object.fromEntries(signatureHeader.split(',').map((p) => p.split('=')))
const expected = createHmac('sha256', secret).update(`${parts.t}.${rawBody}`).digest('hex')
return expected === parts.v1
}O Zoen também envia os headers sim-event, sim-timestamp e Idempotency-Key em cada entrega, para o receptor deduplicar retries.
Retries
Se o seu endpoint não devolver um 2xx, o Zoen tenta de novo até 5 vezes com atrasos crescentes de 5s, 15s, 60s, 3m e depois 10m, cada um com um pouco de jitter. Depois da quinta falha a entrega é marcada como failed.
Configurando um alerta
Configure alertas nas configurações de notificação do workspace, ou pela API de notificações do workspace:
GET /api/workspaces/{id}/notificationslista alertas.POST /api/workspaces/{id}/notificationscria um.PUT /api/workspaces/{id}/notifications/{notificationId}atualiza um.DELETE /api/workspaces/{id}/notifications/{notificationId}remove um.POST /api/workspaces/{id}/notifications/{notificationId}/testenvia um teste.
Criar ou alterar um alerta exige acesso Write ou Admin ao workspace. Um workspace pode ter até 10 alertas de cada tipo de canal.