Acompanhar campanha em tempo real

Após criar campanha, o Syncro tem dashboard ao vivo que mostra progresso em tempo real — KPIs atualizando conforme mensagens vão sendo enviadas, activity feed com últimas execuções, gráficos de variações distribuídas. Tudo via WebSocket (WebSocket) com fallback de polling.

Esse artigo mostra cada parte do dashboard e como interpretar os números.

Acessar o dashboard

1. Em Disparos (rota /disparos), clique no nome da campanha desejada.
2. Cai na página /disparos/{id} com o dashboard.

Layout

Header

• Status pill colorido (azul/amarelo/cinza/verde/vermelho conforme status).
• Nome da campanha.
• Botões de ação (Pausar / Retomar / Cancelar).

KPI cards (4)

Cards no topo mostram contadores em tempo real:

Barra de progresso

• Linear gradient (azul→verde) mostrando progress_pct (0-100%).
• Inclui leads sent + failed + skipped divididos por total_leads.

Activity feed (sidebar direita)

Lista das últimas atividades:

• "João Silva — enviada — 14:32"
• "Maria Costa — falhou — 14:31"
• "Pedro Santos — pulada (janela 24h fechada) — 14:30"

Atualiza em tempo real via WebSocket.

Variações cadastradas

Painel mostrando cada variação:

• Tabs: Variação 1, 2, 3...
• Pra cada uma, preview iPhone com mensagem renderizada.
• Útil pra revisar o que está sendo enviado.

Settings

Resumo das configurações da campanha:

• Lista de leads (link clicável).
• Instância WhatsApp.
• Tipo (texto / imagem).
• Intervalo (min-max).
• Lote + pausa.
• Daily limit.
• Respeita janela 24h: yes/no.

Recipients table

Tabela paginada (50/página) com lista completa de leads da campanha:

Filtro: dropdown pra mostrar só sent, failed, skipped, pending ou all.

Atualizações em tempo real (WebSocket)

O dashboard atualiza automaticamente sem você precisar dar F5:

Como funciona

1. Cada vez que um recipient é processado (sent/failed/skipped), backend dispara evento MassCampaignProgress.
2. Evento é broadcastado via WebSocket no canal privado tenant.{tenantId}.mass-campaigns.
3. JavaScript do dashboard escuta o canal e atualiza UI.
4. KPIs, progresso, activity feed — todos atualizam em segundos.

Throttle inteligente

Pra campanhas pequenas (< 20 leads): broadcast a cada envio (você vê tudo).

Pra campanhas grandes (>= 20 leads): broadcast a cada 5 envios (otimização de performance WebSocket). Não inunda WebSocket com milhares de eventos por segundo.

Último sempre é broadcastado

Mesmo com throttle, o último envio sempre dispara broadcast (pra marcar campanha como completed).

Polling fallback

Se WebSocket cair (rede ruim, servidor reverb offline), dashboard tem fallback de polling:

• A cada 30 segundos, faz GET em /disparos/{id}/recipients.
• Atualiza stats e tabela.

Você não nota a diferença — só talvez um pequeno atraso quando ressorre via polling vs WebSocket.

Stats no payload

Cada broadcast / response contém:

{
 "campaign_id": 123,
 "name": "Promoção Black Friday",
 "status": "running",
 "total_leads": 500,
 "sent_count": 287,
 "failed_count": 5,
 "skipped_count": 12,
 "pending_count": 196,
 "progress_pct": 60.8,
 "last_outcome": "sent",
 "completed_at": null,
 "emitted_at": "2026-04-29T14:32:10Z"
}

Status da campanha

Skip reasons (motivos de pular)

Recipients podem ser pulados por vários motivos. Cada um aparece com skip_reason:

Você consegue filtrar a tabela por skip_reason específico pra investigar.

Erros (status failed)

Se status='failed', sistema preserva a mensagem de erro no campo error:

• "Number does not exist on WhatsApp" — número fora do WhatsApp.
• "Cloud API rate limit" — Meta blocou momentaneamente.
• "Connection timeout" — instância caiu durante envio.

Veja Tabela de recipients > filtro Failed pra investigar.

Casos comuns de monitoramento

"Por que tantos pulados?"

1. Filtre tabela por Skipped.
2. Veja distribuição de skip_reason:

• Muitos invalid_phone → lista mal qualificada (telefones errados).
• Muitos window_closed (Cloud API) → leads há muito sem responder. Considere template HSM ou desativar respect_24h_window.
• Muitos duplicate → você criou recipient pro mesmo lead várias vezes (raro).

"Campanha tá lenta demais"

1. Verifique preset escolhido (Conservador é lento por design).
2. Veja pending_count decrescendo na velocidade esperada.
3. Se sim, é normal pelo preset.
4. Se não está decrescendo: worker pode estar travado. Contate suporte.

"Falhas explodindo"

Se failed_count está alto (>10% de envios):

• Pode ser número banido ou com problema. Verifique.
• Pode ser Cloud API rate limit. Reduza ritmo (próximas campanhas use Conservador).
• Pode ser lista com muitos números fakes. Limpe a lista.

"Campanha parou no meio"

1. Confira status:

• paused: alguém pausou. Resume.
• running mas pending estagnado: worker pode estar morto. Aguarde cron de health (daily 03:30) ressurgir, ou contate suporte.

2. Verifique daily_limit: pode ter atingido e estar pausada até o dia seguinte.

Cron de saúde

Tem um cron mass-campaigns:health que roda diariamente às 03:30 e:

1. Re-enfileira recipients órfãos (jobs perdidos por algum motivo).
2. Marca campanhas concluídas que ainda estavam running mas sem pendentes há +24h.

Garante que campanhas não ficam em estado quebrado indefinidamente.

Métricas pra reportar

Pra extrair dados pra relatórios externos ou apresentação:

• Taxa de envio: sent_count / total_leads × 100%.
• Taxa de erro: failed_count / total_leads × 100%.
• Taxa de skip: skipped_count / total_leads × 100%.
• Tempo de campanha: completed_at - started_at.

Hoje a UI não exporta automaticamente em CSV. Pra extrair, considere:

• Copy-paste da tabela pra Excel.
• API REST v1 se sua versão expõe endpoint de campanhas.
• Pedir ao suporte.

Compartilhar progresso

URL do dashboard /disparos/{id} é acessível só pra usuários do tenant. Pra mostrar resultado pra cliente externo:

• Tire prints dos KPIs e progresso.
• Exporte lista de quem foi atendido (se você tem acesso à lista de leads vinculada).

Próximos passos

• Pra pausar / cancelar campanha, veja Pausar e cancelar.
• Pra criar nova campanha, veja Criar campanha.

Artigos relacionados

• Criar campanha
• Pausar e cancelar campanha
• Regras anti-banimento