- SLA = promessa externa; SLO = meta interna; SLI = métrica que você mede
- Em automações, os SLIs mais úteis são: sucesso/falha, latência end-to-end, backlog (pendências) e frescor do dado
- Error budget ajuda a decidir quando parar de criar fluxo novo e consertar a operação
- Alertas bons são acionados por tendência e impacto (degradação), não por falha isolada
1) Escolha o “evento de negócio” que define sucesso
Pare de medir só “workflow rodou”. Defina um resultado verificável: lead criado no CRM + mensagem enviada; pedido faturado + nota emitida; boleto conciliado + baixa registrada. Sem isso, seu SLA vira opinião.
2) Escreva o SLA em linguagem de pessoa (e com escopo)
Exemplo de formato: “Quando um lead preencher o formulário (gatilho), até N minutos ele deve estar no CRM e receber o primeiro contato (resultado), em M% das vezes (confiabilidade), dentro do horário comercial (escopo)”. Se houver horários, filas manuais ou dependência de API de terceiros, coloque no texto.
3) Defina 2–3 SLIs que você consegue medir de verdade
SLIs típicos: taxa de sucesso (execuções concluídas sem erro), latência end-to-end (do evento ao resultado), backlog/atraso (itens pendentes, filas, reexecuções) e frescor do dado (quanto tempo desde a última execução OK). Evite começar com 10 métricas: vira dashboard bonito e operação cega.
4) Transforme SLIs em SLOs com números negociáveis
Escolha metas coerentes com impacto. Em vez de copiar “99,9%”, pergunte: quantas falhas por semana o time aguenta sem virar incêndio? Se você não tem histórico, comece com uma meta provisória e revise após 2–4 semanas de medição. Dado exato depende do volume e criticidade; aqui vale assumir que o primeiro SLO é um rascunho.
5) Crie um error budget e uma regra de parada
Error budget é o “quanto pode dar errado” antes de virar prioridade de correção. Ex.: se a taxa de sucesso cair abaixo do SLO ou se o backlog ultrapassar um limite por tempo contínuo, congela-se criação de novas automações para estabilizar. Isso evita a espiral: mais fluxo novo + operação pior.
6) Desenhe alertas por impacto (e com antirruído)
Três alertas que costumam valer mais que vinte: (a) falhas consecutivas (ex.: 3–5 seguidas), (b) latência acima do limite por janela de tempo (ex.: 10–15 min), (c) backlog crescendo (sinal de gargalo/limite de API). Use janela e agregação para não acordar o time por erro pontual.
7) Feche o ciclo: runbook curto + pós-incidente
Para cada alerta, escreva um runbook de 5 linhas: onde olhar logs, como reprocessar com segurança, como pausar gatilhos, e como validar que o resultado foi entregue (não só “workflow verde”). Depois, registre causa raiz: credencial expirada, rate limit, payload diferente, timeout, dependência externa.
SLA, SLO e SLI: o trio sem misticismo
SLA (Service Level Agreement) é o combinado com o negócio ou com o cliente: prazo, disponibilidade, qualidade do resultado. Em automação, SLA costuma virar dor quando é escrito como “o fluxo não pode falhar”, porque falhar vai — API cai, token expira, planilha muda coluna, webhook chega duplicado.
SLO (Service Level Objective) é a meta interna que você controla e mede para sustentar o SLA. Ele vive no seu painel/relatório e vira critério de prioridade.
SLI (Service Level Indicator) é a métrica em si: sucesso, tempo, atrasos. Se você não mede, não é SLI — é esperança.
| Termo | Pergunta que responde | Exemplo em automação |
|---|---|---|
| SLA | O que eu prometo para alguém? | “Novo lead recebe contato em até X minutos no horário comercial” |
| SLO | Que meta interna garante o SLA? | “95% dos leads processados em até X minutos” |
| SLI | O que eu vou medir para saber? | Tempo do evento (form) até mensagem enviada + status de entrega |
Quais métricas mais funcionam em n8n/Make/Zapier (na prática)
A tentação é medir tudo: cada nó, cada módulo, cada webhook. Mas a operação melhora quando você mede o que representa risco real para o negócio.
Quatro SLIs que costumam dar retorno rápido:
- Taxa de sucesso end-to-end: o resultado final foi entregue?
- Latência end-to-end: quanto tempo o processo levou do gatilho ao efeito?
- Backlog/pendências: existe fila de itens esperando (ou reprocessos acumulando)?
- Frescor do dado: há quanto tempo não ocorre uma execução bem-sucedida?
Como escolher metas sem histórico (sem inventar 99,9%)
Sem histórico, você não tem base para um número “certo”. O caminho mais honesto é começar com meta provisória e revisitar.
Um método simples: classifique a automação por criticidade e tolerância a atraso. Uma cobrança automática tem tolerância baixa; um relatório diário pode tolerar mais. Depois, escolha SLOs que você consegue cumprir consistentemente e que façam diferença no resultado.
Se o seu volume é baixo, porcentagens enganam: 1 falha pode derrubar um mês inteiro. Nesses casos, complemente com metas absolutas (ex.: “no máximo N incidentes por mês”) e com SLO de latência/backlog.
Modelo rápido de SLO por tipo de automação
Abaixo vai um ponto de partida (não é regra universal). Ajuste ao seu contexto, integrações e horário de operação.
| Tipo | SLIs recomendados | SLO típico (ponto de partida) |
|---|---|---|
| Tempo real (webhook/lead/WhatsApp) | sucesso end-to-end, latência, falhas consecutivas | latência em minutos + sucesso em janela semanal/mensal |
| Backoffice (faturamento/estoque) | sucesso, backlog, reprocesso seguro | backlog máximo + sucesso por lote/dia |
| Relatórios/BI | frescor do dado, sucesso, duração | “dado atualizado até hh:mm” + execução diária OK |
| Integrações com limite de API | backoff/retry, backlog, taxa de erro 429 | backlog controlado + erro 429 abaixo de limite aceitável |
Alertas: o que mais reduz incidentes (e o que só gera ruído)
Alerta bom tem duas características: aponta impacto e já sugere triagem. “Falhou 1 vez” raramente é impacto; “falhou 5 vezes seguidas” geralmente é.
O ruído mais comum em automações é alerta por exceção isolada (payload diferente, timeout momentâneo, oscilação de API). Prefira janelas e tendências.
- Prefira: falhas consecutivas, taxa de falha por janela, latência acima do limite por 10–15 min, backlog crescente
- Evite: alerta a cada erro individual sem agregação
- Inclua no alerta: qual fluxo, qual integração, últimos IDs processados, e se há risco de duplicidade no reprocesso
Perguntas frequentes
SLA e SLO servem para automação pequena ou só para empresa grande?
Qual a diferença entre “o workflow rodou” e “o processo deu certo”?
Como lidar com terceiros (APIs instáveis) na meta?
O que é error budget em automação e por que isso muda o jogo?
Leia também
Como monitorar automações (n8n, Make e Zapier): alertas, logs e erros sem virar refém do “falhou e ninguém viu”
Guia prático para monitorar automações em n8n, Make e Zapier: quais alertas criar, como registrar logs, tratar erros, retries e evitar falhas silenciosas.
Ler →
Observabilidade no n8n self-hosted: como montar métricas, logs e alertas (sem adivinhação)
Guia prático para monitorar n8n self-hosted com logs, métricas e alertas. O que medir, como estruturar correlação por execução e como evitar “apagão” quando um fluxo falha.
Ler →
Timeout e cancelamento em automações no n8n: como evitar workflow travado e webhook expirado
Guia prático para lidar com timeout, execução longa e cancelamento no n8n: padrões de arquitetura, filas, retry e respostas assíncronas para não travar operação.
Ler →
Como calcular ROI de automação (n8n, Make, Zapier) sem se enganar na conta
Um guia prático para calcular ROI de automação com horas economizadas, custos de operação, falhas e manutenção. Inclui fórmula, checklist e exemplos do que entra (e do que muita gente esquece).
Ler →