Quando uma mensagem falha, Otto faz retry automático conforme política definida por tipo de falha. Esta página descreve o que é retentado, quantas vezes e quando você precisa intervir manualmente.
Princípio: retry inteligente
Retry cego em qualquer erro é desperdício e pode irritar cliente. Otto separa falhas em transitórias (vale tentar de novo) e permanentes (não vale).
| Tipo de falha | Retry? |
|---|---|
| Provider retornou 5xx | Sim |
| Timeout de rede | Sim |
| Rate limit do provider | Sim (com delay) |
| Token de plataforma expirado | Não — corrige config |
| Telefone inválido | Não |
| Email inválido | Não |
| Cliente bloqueou nosso número | Não |
| Cota mensal esgotada | Não — sobe plano |
| Janela fechada | Adia (não conta como retry) |
Política padrão
Para falhas transitórias:
| Tentativa | Delay antes |
|---|---|
| 1 | imediato |
| 2 | 30 segundos |
| 3 | 2 minutos |
| 4 | 10 minutos |
| 5 | 1 hora |
Após 5 tentativas sem sucesso, status vai para failed e Otto não tenta mais automaticamente.
Retry vs delay
Não confunda:
- Retry = tentar de novo após falha
- Delay = adiar por janela fechada, quiet hours, ordem de sequência
Delay não conta no contador de retry. Mensagem pode ficar delayed por 12h sem queimar tentativa.
Onde ver retries
Em Otto > Mensagens > [Mensagem], aba Histórico:
00:00:00 → queued
00:00:01 → sending
00:00:03 → failed (provider 502)
00:00:33 → sending (retry 2)
00:00:35 → failed (provider 502)
00:02:35 → sending (retry 3)
00:02:37 → sent → deliveredCada linha mostra timestamp e estado.
Quando intervir manualmente
Caso 1: falha por config (token expirado)
- Otto não retenta sozinho
- Mensagem vai para
failed - Você corrige config (reconectar plataforma, refazer DKIM)
- Em Otto > Mensagens, selecione as falhadas e clique em Reenviar
Caso 2: cota esgotada
- Otto não retenta
- Mensagem vai para
failedcom erroquota_exceeded - Você sobe plano ou espera o ciclo
- No próximo ciclo, mensagens não retentam sozinhas — você precisa reprocessar lote (ver Reprocessar lote)
Caso 3: provider deu falha massiva
- Otto retenta automático até 5x
- Se persistir, todas viram
failed - Após o provider voltar, reprocesse o lote manualmente
- Detalhes em Reprocessar lote
Reenviar mensagem individual
- Otto > Mensagens > [Mensagem].
- Botão Reenviar agora.
- Confirme.
A mensagem volta para a fila com prioridade alta. Conta como nova tentativa e o histórico anterior fica preservado.
Atenção: reenviar mensagem que já foideliveredcria duplicata. Cuide para não fazer isso por engano — alerta aparece se hádeliveredno histórico.
Reenviar lote
Para reenviar muitas falhas de uma vez, ver Reprocessar lote.
Cancelando retries pendentes
Para parar retries automáticos antes de esgotar:
- Otto > Mensagens > [Mensagem].
- Botão Cancelar.
Status vira cancelled. Não há retry após.
Bounce de email
Email tem categorias específicas:
| Tipo | O que é | Otto faz |
|---|---|---|
| Hard bounce | Email não existe | Marca como bounce, suprime endereço |
| Soft bounce | Caixa cheia, indisponível | Retenta até 3x em 48h |
| Complaint | Cliente marcou como spam | Marca, suprime, nunca envia de novo |
| Suppression list | Já estava na lista | Não envia, marca suppressed |
Endereços com hard bounce ou complaint vão para suppression list automaticamente. Detalhes em Lista de supressão de email.
<!-- TODO: artigo email-suppression-list ainda não existe; criar se houver demanda -->
Falha por cliente que bloqueou
WhatsApp permite o cliente bloquear seu número. Quando isso acontece:
- Mensagens dão erro
blocked_by_user - Otto não retenta
- Cliente é marcado em Clientes > [Cliente] > Status: bloqueado
- Otto não envia para esse cliente em outras automações
Detalhes em Cliente não recebeu mensagens.
Métricas de retry
Otto > Métricas > Saúde de envio mostra:
- Taxa de sucesso (sent/total)
- Taxa de retry (msgs que precisaram retentar)
- Taxa de falha permanente
Saudável: <2% de falhas permanentes, <10% de retries.
Acima desses números, abrir ticket — pode haver problema de config ou de provider.
Logs detalhados
Para investigação técnica, Monitoramento > Logs (admin) mostra logs do worker que processou cada job. Como lojista, peça ao suporte se precisar.