Aprenda um roteiro prático para construir um web app que rastreia timers de SLA, detecta violações instantaneamente, alerta equipes e visualiza conformidade em tempo real.
Antes de desenhar telas ou escrever a lógica de detecção, esclareça exatamente o que seu app tenta prevenir. “Monitoramento de SLA” pode significar qualquer coisa entre um relatório diário e previsão de violação segundo a segundo—são produtos muito diferentes com necessidades arquiteturais bem distintas.
Comece concordando com a janela de reação que sua equipe consegue executar realisticamente.
Se sua organização de suporte opera em ciclos de 5–10 minutos (filas de triagem, rotações de plantão), então “tempo real” pode significar atualizações do painel a cada minuto com alertas em até 2 minutos. Se você lida com incidentes de alta severidade onde minutos importam, pode ser necessário um loop de detecção e alerta de 10–30 segundos.
Escreva isso como uma meta mensurável, por exemplo: “Detectar potenciais violações em até 60 segundos e notificar o plantonista em até 2 minutos.” Isso vira um guardrail para trade-offs posteriores em arquitetura e custo.
Liste as promessas específicas que você está acompanhando e defina cada uma em linguagem simples:
Observe também como isso se relaciona com as definições de SLO e SLA na sua organização. Se seu SLO interno difere do SLA para o cliente, seu app pode precisar rastrear ambos: um para melhoria operacional, outro para risco contratual.
Nomeie os grupos que usarão ou dependerão do sistema: suporte, engenharia, customer success, líderes/gerentes de time e resposta a incidentes/plantão.
Para cada grupo, capture o que precisam decidir no momento: “Este ticket está em risco?”, “Quem é o dono?”, “Precisamos escalar?” Isso vai moldar seu dashboard, roteamento de alertas e permissões.
O objetivo não é só visibilidade—é ação oportuna. Decida o que deve acontecer quando o risco aumenta ou uma violação ocorre:
Uma boa declaração de resultado: “Reduzir violações de SLA possibilitando detecção de violação e resposta a incidentes dentro da nossa janela de reação acordada.”
Antes de construir a lógica de detecção, escreva exatamente o que significa “bom” e “ruim” para seu serviço. A maioria dos problemas de monitoramento de SLA não é técnica—é de definição.
Um SLA (Service Level Agreement) é uma promessa ao cliente, normalmente com consequências (créditos, penalidades, termos contratuais). Um SLO (Service Level Objective) é uma meta interna que você busca para se manter acima do SLA. Um KPI (Key Performance Indicator) é qualquer métrica que você acompanha (útil, mas nem sempre ligada a uma promessa).
Exemplo: SLA = “responder em até 1 hora.” SLO = “responder em até 30 minutos.” KPI = “média do tempo até a primeira resposta.”
Liste cada tipo de violação que precisa ser detectado e o evento que inicia o relógio.
Categorias comuns de violação:
Seja explícito sobre o que conta como “resposta” (resposta pública vs nota interna) e “resolução” (resolvido vs fechado), e se reabrir reseta o relógio.
Muitos SLAs contabilizam apenas o tempo durante o horário comercial. Defina o calendário: dias úteis, feriados, horários de início/fim, e o fuso horário usado para cálculo (do cliente, do contrato ou da equipe). Decida também o que ocorre quando o trabalho cruza esses limites (por exemplo, um ticket chega às 16:55 com SLA de 30 minutos).
Documente quando o relógio do SLA para, como:
Escreva essas regras para que o app possa aplicá-las de forma consistente e mantenha exemplos de casos complicados para testes posteriores.
Seu monitor de SLA é tão bom quanto os dados que o alimentam. Comece identificando os “sistemas de registro” para cada relógio de SLA. Para muitas equipes, a ferramenta de ticketing é a fonte da verdade para timestamps de ciclo de vida, enquanto ferramentas de monitoramento e logs explicam o porquê de algo ter acontecido.
A maioria das configurações em tempo real puxa de um pequeno conjunto de sistemas principais:
Se dois sistemas discordarem, decida antecipadamente qual vence para cada campo (por exemplo: “status do ticket vem do ServiceNow, tier do cliente vem do CRM”).
No mínimo, monitore eventos que iniciam, param ou alteram o relógio de SLA:
Considere também eventos operacionais: mudanças no calendário de horário comercial, atualizações de fuso do cliente e alterações no cronograma de feriados.
Prefira webhooks para atualizações quase em tempo real. Use polling quando webhooks não estiverem disponíveis ou confiáveis. Mantenha exportações via API/backfills para reconciliação (por exemplo, jobs noturnos que preenchem lacunas). Muitas equipes acabam com um híbrido: webhook para velocidade, polling periódico para segurança.
Sistemas reais são bagunçados. Espere:
Trate esses pontos como requisitos de produto, não “casos de borda”—sua detecção de violação depende disso.
Um bom app de monitoramento de SLA é mais fácil de construir (e manter) quando a arquitetura é clara e intencionalmente simples. Em alto nível, você está construindo um pipeline que transforma sinais operacionais brutos em “estado de SLA”, e então usa esse estado para alertar pessoas e alimentar um dashboard.
Pense em cinco blocos:
Essa separação mantém responsabilidades limpas: ingestão não deve conter lógica de SLA, e dashboards não devem executar cálculos pesados.
Decida cedo quão “tempo real” você realmente precisa ser.
Uma abordagem pragmática é começar com recalculo frequente para uma ou duas regras de SLA, depois mover regras de alto impacto para streaming.
Evite complexidade multi-região e multi-ambiente no início. Uma única região, um ambiente de produção e um staging mínimo geralmente são suficientes até validar qualidade de dados e utilidade dos alertas. Faça “escalar depois” ser uma restrição de design, não um requisito de construção.
Se quiser acelerar a primeira versão funcional do dashboard e dos workflows, uma plataforma de scaffolding como Koder.ai pode ajudar a gerar uma UI React e um backend Go + PostgreSQL rapidamente a partir de uma especificação conversacional, e então iterar nas telas e filtros enquanto valida o que os respondedores realmente precisam.
Anote antes de implementar:
Ingestão de eventos é onde seu sistema de monitoramento de SLA ou se torna confiável—ou barulhento e confuso. O objetivo é simples: aceitar eventos de muitas ferramentas, convertê-los para um formato único de “verdade” e armazenar contexto suficiente para explicar cada decisão de SLA depois.
Padronize o que um “evento relevante para SLA” parece, mesmo que sistemas a montante variem. Um schema prático inclui:
ticket_id (ou case/work item ID)timestamp (quando a mudança aconteceu, não quando você a recebeu)status (opened, assigned, waiting_on_customer, resolved, etc.)priority (P1–P4 ou equivalente)customer (identificador da conta/tenant)sla_plan (quais regras de SLA se aplicam)Versione o schema (ex.: schema_version) para evoluir campos sem quebrar produtores antigos.
Sistemas diferentes chamam a mesma coisa de modos distintos: “Solved” vs “Resolved”, “Urgent” vs “P1”, diferenças de fuso, ou prioridades ausentes. Construa uma pequena camada de normalização que:
is_customer_wait ou is_pause) que simplifiquem a lógica de violação depoisIntegrações reais fazem retry. Sua ingestão deve ser idempotente para que eventos repetidos não criem duplicatas. Abordagens comuns:
event_id do produtor e rejeitar duplicadosticket_id + timestamp + status) e upsertQuando alguém perguntar “Por que avisamos?”, você precisa de um histórico. Armazene todo evento bruto aceito e cada evento normalizado, além de quem/o que o mudou. Esse histórico de auditoria é essencial para conversas com clientes e revisões internas.
Alguns eventos falharão ao parsear ou validar. Não os descarte silenciosamente. Encaminhe-os para uma dead-letter queue/tabela com a razão do erro, payload original e contagem de tentativas, para que você corrija mappings e reprocessamentos com segurança.
Seu app de SLA precisa de duas “memórias” diferentes: o que é verdade agora (para disparar alertas) e o que aconteceu ao longo do tempo (para explicar e provar por que alertou).
Estado atual é o último status conhecido de cada item (ticket/incidente/pedido) mais seus timers ativos de SLA (start time, paused time, due time, minutos restantes, dono atual).
Escolha um storage otimizado para leituras/gravações rápidas por ID e filtragem simples. Opções comuns são banco relacional (Postgres/MySQL) ou key-value (Redis/DynamoDB). Para muitas equipes, Postgres é suficiente e mantém relatórios simples.
Mantenha o modelo de estado enxuto e amigável a consultas. Você vai lê-lo constantemente para views como “em risco de violar”.
O histórico deve capturar cada mudança como um registro imutável: criado, atribuído, prioridade alterada, status atualizado, cliente respondeu, on-hold iniciado/terminado, etc.
Uma tabela de eventos append-only (ou event store) possibilita auditoria e replays. Se você descobrir um bug na lógica de violação, pode reprocessar eventos para reconstruir estado e comparar resultados.
Padrão prático: tabela de estado + tabela de eventos no mesmo banco inicialmente; migre para storage analítico separado se o volume crescer.
Defina retenção por propósito:
Use particionamento (por mês/trimestre) para tornar arquivamento e deletes previsíveis.
Planeje para as perguntas que seu dashboard fará com mais frequência:
due_at e status (e possivelmente queue/team).breached_at (ou flag de violação computada) e data.(customer_id, due_at).É aqui que o desempenho se conquista: estruture o armazenamento em torno de suas 3–5 views principais, não de todo relatório possível.
Detecção em tempo real de violação é, em grande parte, sobre uma coisa: transformar workflows humanos (atribuído, aguardando cliente, reaberto, transferido) em timers de SLA claros e confiáveis.
Defina quais eventos controlam o relógio de SLA para cada tipo de ticket ou solicitação. Padrões comuns:
A partir desses eventos, calcule um due time. Para SLAs estritos, pode ser created_at + 2 hours. Para SLAs em horário comercial, é “2 horas úteis”, o que requer um calendário.
Crie um pequeno módulo de calendário que responda duas perguntas de forma consistente:
Mantenha feriados, horários de trabalho e fusos em um só lugar para que toda regra de SLA use a mesma lógica.
Uma vez que você tem um due time, calcular tempo restante é simples: due_time - now (em minutos úteis, se aplicável). Depois defina thresholds de risco de violação como “vence em 15 minutos” ou “menos de 10% do SLA restante”. Isso alimenta badges de urgência e roteamento de alertas.
Você pode:
Um híbrido prático é: updates orientados a evento para precisão, mais um tick de minuto para pegar cruzamentos de thresholds baseados em tempo mesmo sem novos eventos.
Alertas é onde o monitoramento de SLA vira operação. O objetivo não é “mais notificações”—é fazer a pessoa certa executar a ação certa antes do prazo estourar.
Use um conjunto pequeno de tipos de alerta com intenção clara:
Mapeie cada tipo a uma urgência e canal de entrega diferentes (chat para avisos, paging para violações confirmadas, etc.).
O roteamento deve ser orientado por dados, não hard-coded. Use uma tabela simples de regras como: serviço → time responsável, depois aplique modificadores:
Isso evita “enviar para todo mundo” e torna a propriedade visível.
O status de SLA pode oscilar rapidamente durante a resposta a incidentes. Dedup por uma chave estável como (ticket_id, sla_rule_id, alert_type) e aplique:
Considere também agrupar vários avisos em um resumo periódico.
Cada notificação deve responder “o que, quando, quem, e o próximo passo”:
Se alguém não consegue agir em 30 segundos após ler, o alerta precisa de contexto melhor.
Um bom dashboard de SLA é menos sobre gráficos e mais sobre ajudar alguém a decidir o que fazer a seguir em menos de um minuto. Desenhe a UI em torno de três perguntas: O que está em risco? Por quê? O que devo fazer?
Comece com quatro visões simples, cada uma com propósito claro:
Mantenha a view padrão focada em vencendo em breve, pois é aí que a prevenção acontece.
Dê aos usuários um pequeno conjunto de filtros que mapeiem para propriedade e decisões reais de triagem:
Torne filtros persistentes por usuário para que não precisem reconfigurar a cada visita.
Cada linha em “vencendo em breve” deve incluir uma explicação curta em português simples, por exemplo:
Adicione um drawer “Detalhes” que mostre a linha do tempo de mudanças de estado de SLA (iniciado, pausado, retomado, violado), para que o usuário confie no cálculo sem precisar fazer contas.
Projete o fluxo padrão como: revisar → abrir → agir → confirmar.
Cada item deve ter botões de ação que saltem para a fonte da verdade:
Se suportar ações rápidas (atribuir, mudar prioridade, adicionar nota), mostre-as apenas onde puder aplicá-las de forma consistente e audite a mudança.
Um app de monitoramento de SLA vira rapidamente um sistema de registro para desempenho, incidentes e impacto ao cliente. Trate-o como software de produção desde o dia um: limite quem pode fazer o quê, proteja dados sensíveis e documente como os dados são armazenados e removidos.
Comece com um modelo de permissões pequeno e claro e expanda só quando necessário. Uma configuração comum é:
Mantenha permissões alinhadas com workflows. Ex.: um operator pode atualizar status do incidente, mas só um admin altera timers de SLA ou regras de escalonamento.
Monitoramento de SLA frequentemente inclui identificadores de cliente, tiers contratuais e conteúdo de tickets. Minimize exposição:
Integrações são pontos fracos frequentes:
Defina políticas antes de acumular meses de histórico:
Escreva essas regras e reflita-as na UI para que a equipe saiba o que o sistema mantém—e por quanto tempo.
Testar um app de monitoramento de SLA é menos sobre “a UI carrega?” e mais sobre “os timers, pausas e thresholds são calculados exatamente como o contrato exige—toda vez.” Um pequeno erro (fusos horários, horários comerciais, eventos faltantes) pode gerar alertas ruidosos ou, pior, violações perdidas.
Transforme suas regras de SLA em cenários concretos que você pode simular de ponta a ponta. Inclua fluxos normais e casos de borda desconfortáveis:
Comprove que sua lógica de detecção é estável sob a bagunça operacional real, não apenas com dados limpos de demonstração.
Crie fixtures replayáveis: uma pequena biblioteca de “linhas do tempo de incidente” que você possa rodar pela ingestão e cálculo sempre que mudar lógica. Isso ajuda a verificar cálculos ao longo do tempo e evita regressões.
Mantenha fixtures versionadas (no Git) e inclua saídas esperadas: tempo restante calculado, momento da violação, janelas de pausa e gatilhos de alerta.
Trate o monitor de SLA como qualquer sistema de produção e adicione sinais de saúde próprios:
Se seu dashboard mostra “verde” enquanto eventos estão presos, você perderá confiança rapidamente.
Escreva um runbook curto e claro para falhas comuns: consumidores travados, mudanças de schema, outages a montante e backfills. Inclua passos para reprocessar eventos e recalcular timers com segurança (qual período, quais tenants e como evitar double-alerting). Linke isso na sua documentação interna ou em uma página simples como /runbooks/sla-monitoring.
Lançar um app de monitoramento de SLA é mais fácil quando você o trata como um produto, não um projeto pontual. Comece com uma versão mínima viável que prove o loop end-to-end: ingest → avaliar → alertar → confirmar que ajudou alguém a agir.
Escolha uma fonte de dados, um tipo de SLA e alertas básicos. Por exemplo, monitore “primeira resposta” usando um único feed do ticketing, e envie um alerta quando o relógio estiver prestes a expirar (não só após violar). Isso mantém o escopo contido enquanto valida as partes mais difíceis: timestamps, janelas de tempo e propriedade.
Depois que o MVP estiver estável, expanda em passos pequenos: adicione um segundo tipo de SLA (ex.: resolução), depois uma segunda fonte de dados, depois workflows mais ricos.
Configure dev, staging e production cedo. O staging deve espelhar configurações de produção (integrações, agendas, caminhos de escalonamento) sem notificar respondedores reais.
Use feature flags para liberar:
Se estiver construindo rápido com uma plataforma como Koder.ai, snapshots e rollback são úteis: você pode entregar UI e mudanças de regra a um piloto e reverter se os alertas ficarem ruidosos.
Escreva docs curtas e práticas: “Conectar fonte de dados”, “Criar um SLA”, “Testar um alerta”, “O que fazer ao ser notificado”. Mantenha-as próximas ao produto, como uma página interna em /docs/sla-monitoring.
Após adoção inicial, priorize melhorias que aumentem confiança e reduzam ruído:
Itere com base em incidentes reais: cada alerta deve ensinar o que automatizar, esclarecer ou remover.
Um objetivo de monitoramento de SLA é uma declaração mensurável que define:
Escreva isso como um objetivo que você pode testar: “Detectar potenciais violações dentro de X segundos e notificar plantonista dentro de Y minutos.”
Defina “tempo real” com base na capacidade da sua equipe de responder, não apenas no que é tecnicamente possível.
O importante é assumir um (evento → cálculo → alerta/painel) e projetar a solução em torno disso.
Monitore as promessas ao cliente que podem ser efetivamente violadas (e possivelmente gerar créditos), tipicamente:
Muitas equipes também acompanham um interno mais rígido que o SLA. Se você tem ambos, armazene e exiba os dois para que os operadores ajam cedo enquanto reportam conformidade contratual corretamente.
Falhas em SLA costumam ser falhas de definição. Esclareça:
Depois codifique essas regras de forma determinística e mantenha uma biblioteca de linhas do tempo de exemplo para testá-las.
Defina um conjunto consistente de regras de calendário:
Implemente um módulo de calendário reutilizável que responda:
Escolha um “sistema de registro” por campo e documente qual fonte vence quando houver desacordo.
Fontes típicas:
Para comportamento quase em tempo real, prefira ; adicione para reconciliação e eventos perdidos.
No mínimo, capture eventos que iniciam, param ou modificam o relógio de SLA:
Também planeje eventos que “as pessoas esquecem”, como atualizações do calendário de negócios, mudanças de fuso horário e feriados — eles podem alterar due times sem atividade no ticket.
Use um pipeline simples em cinco blocos:
Use ambos, conforme a urgência:
Um híbrido sólido é: atualizações por eventos para correção, mais um tick de nível de minuto para capturar cruzamentos de limiar mesmo sem novos eventos (por exemplo, “vence em 15 minutos”).
Considere alertas como um fluxo de trabalho, não como um despejo de notificações:
Mantenha a lógica de SLA fora da ingestão e cálculos pesados fora dos dashboards. Comece com uma implantação simples (uma região, ambientes mínimos) até confiar na qualidade dos dados e na utilidade dos alertas.
(work_item_id, sla_rule_id, alert_type) e envie apenas em transições de estado com um cooldown.Cada alerta deve incluir: dono/plantonista, due time e tempo restante, próxima ação e links como /tickets/{id} e /sla/tickets/{id}.