Vigilia

Configurar o Vigilia

Uma única tag de script para começar. Todo o resto — sua IA, alertas, a API — é opcional e leva um minuto cada.

Instalar

Adicione seu aplicativo no painel e ele mostra esta tag com sua chave preenchida. Ela vai no <head> de cada página:

<script src="https://cdn.getvigilia.com/vigilia.js" data-key="vgl_pub_…" defer></script>

Onde isso fica, por framework:

Framework	Onde a tag vai
HTML puro	Cole a tag dentro de <head> de cada página HTML (geralmente apenas index.html), antes de </head>.
Vite, Lovable, Bolt, a maioria dos apps React	Cole a tag dentro de <head> do index.html na raiz do projeto (Lovable, Bolt e a maioria dos apps React/Vite).
Next.js (app router)	Em app/layout.tsx, renderize <Script src="…" data-key="…" strategy="afterInteractive" /> (de next/script) dentro de <body>, mantendo cada atributo data- que a tag possui. O vigilia.js encontra sua própria tag mesmo quando injetada após o carregamento.
Next.js (pages router)	Em pages/_document.tsx, adicione a tag dentro de <Head> (de next/document), mantendo cada atributo data- que ela possui.
SvelteKit	Cole a tag dentro de <head> de src/app.html, antes de %sveltekit.head%.
Astro	Cole a tag dentro de <head> do seu layout compartilhado (ex.: src/layouts/Layout.astro), com is:inline para que o Astro não a altere.
Remix	Em app/root.tsx, adicione a tag dentro de <head>, depois de <Links />.
Nuxt	No nuxt.config, adicione-a em app.head.script como { src, "data-key": …, defer: true }, além de "data-endpoint" se a tag tiver um.

Construiu com um builder de IA? Não cole você mesmo: o painel fornece um prompt que diz ao Lovable, Bolt, Cursor ou Claude Code exatamente o que adicionar — e o que não tocar.

Ou instale pelo npm

Escrevendo o código você mesmo, com um bundler? O mesmo SDK está no npm como @getvigilia/browser. Use-o em vez da tag, não ambos; o painel preenche sua chave.

npm install @getvigilia/browser

import { init } from '@getvigilia/browser';

// Once, as early as the app starts (main.tsx, or the root layout).
init({ key: 'vgl_pub_…', endpoint: 'https://cdn.getvigilia.com/v1/events' });

Empacotado no seu aplicativo, ele precisa apenas da linha connect-src abaixo.

Se o seu site tem uma Content-Security-Policy

Somente então: adicione estes dois endereços às diretivas que você já tem. Mantenha todo o resto.

script-src  https://cdn.getvigilia.com
connect-src https://cdn.getvigilia.com

Um script bloqueado é o motivo mais comum para uma nova instalação não mostrar nada. A verificação de instalação na página do aplicativo lê seu site ao vivo e informa se é isso que está acontecendo.

Opcional: aponte para a linha exata

Publique source maps e o Vigilia resolve uma falha no seu bundle minificado para o seu próprio arquivo e linha (src/pages/Checkout.tsx:42), no incidente e no prompt de correção. Ele os busca apenas durante o diagnóstico. No Vite, build.sourcemap: 'hidden' os escreve sem apontar a página para eles. No Next.js, é productionBrowserSourceMaps: true.

Verifique se funciona

Publique e depois abra seu aplicativo com ?vigilia_test=1 no endereço (a página de configuração tem o link pronto). O Vigilia envia um erro de teste claramente rotulado e um primeiro incidente aparece em segundos. Nada na sua página quebra.

Erros de servidor

Erros no seu backend (uma edge function do Supabase, uma rota de API do Next.js, um Cloudflare Worker) nunca chegam ao navegador do visitante, então o script não consegue vê-los. @getvigilia/server os envia ao Vigilia, onde se tornam incidentes como qualquer outro: em linguagem simples, com um prompt de correção para o seu builder. São apenas erros (sem tracing, sem logs), não tem dependências e nunca lança exceções no seu código. Erros de servidor fazem parte do Pro.

1. Dois segredos

Na página do seu aplicativo, em Server errors, crie uma chave de servidor. Ela é mostrada apenas uma vez. Defina-a e o endpoint onde seu backend roda, nunca no código:

VIGILIA_SERVER_KEY=vgk_…
VIGILIA_ENDPOINT=https://cdn.getvigilia.com/v1/server/events

2. Envolva seus handlers

Um handler envolvido reporta qualquer coisa que ele lance e qualquer 5xx que ele retorne, com o texto do erro de um corpo como { "error": "…" }. A resposta em si nunca é tocada.

Supabase Edge Functions

import { withVigilia, watchAI } from 'https://cdn.getvigilia.com/server.mjs';

watchAI(); // also: AI calls that fail (out of credit, key rejected)

Deno.serve(withVigilia(async (req) => {
  // …your function, unchanged
}, { route: 'checkout' })); // the function's name

No Supabase: Project Settings → Edge Functions → Secrets, ou com supabase secrets set.

Next.js / Vercel

npm install @getvigilia/server

import { withVigilia, watchAI } from '@getvigilia/server';

watchAI(); // also: AI calls that fail (out of credit, key rejected)

export const POST = withVigilia(async (request: Request) => {
  // …your route, unchanged
});

Na Vercel: Project → Settings → Environment Variables, para Production. Localmente, em .env.local.

Cloudflare Workers

npm install @getvigilia/server

import { withVigilia, watchAI } from '@getvigilia/server';

watchAI(); // also: AI calls that fail (out of credit, key rejected)

export default withVigilia({
  async fetch(request, env, ctx) {
    // …your worker, unchanged
  },
});

Como segredos do Worker: execute npx wrangler secret put VIGILIA_SERVER_KEY e depois o mesmo para VIGILIA_ENDPOINT.

Node / Express

npm install @getvigilia/server

import { vigiliaErrorHandler, watchAI } from '@getvigilia/server';

watchAI(); // also: AI calls that fail (out of credit, key rejected)

// after your routes:
app.use(vigiliaErrorHandler());

Nas variáveis de ambiente do seu host (ou em um arquivo .env que seu aplicativo carrega).

Já usa OpenTelemetry? (Team)

Nenhum pacote necessário: adicione o Vigilia como mais um exporter. Seus traces e logs continuam indo para onde vão hoje; o Vigilia mantém apenas exceções e logs de ERROR e descarta o resto na chegada. OTLP sobre HTTP, codificação JSON.

# OpenTelemetry Collector: add Vigilia next to your existing exporters.
exporters:
  otlphttp/vigilia:
    endpoint: https://cdn.getvigilia.com/otlp
    encoding: json
    headers:
      authorization: Bearer ${env:VIGILIA_SERVER_KEY}

service:
  pipelines:
    logs:
      exporters: [otlphttp/vigilia]   # keep the ones already here
    traces:
      exporters: [otlphttp/vigilia]

# No Collector? Point the SDK at Vigilia instead (this replaces its current destination):
# OTEL_EXPORTER_OTLP_ENDPOINT=https://cdn.getvigilia.com/otlp
# OTEL_EXPORTER_OTLP_PROTOCOL=http/json
# OTEL_EXPORTER_OTLP_HEADERS=authorization=Bearer <your server key>

Redija na origem (opcional). O Vigilia limpa cada registro na chegada: e-mails, tokens, números parecidos com cartões e números de contas bancárias (IBANs). Pelo OpenTelemetry, essa é a única limpeza que um registro recebe, porque ele sai da sua rede como foi registrado. Para redigir antes de sair, adicione o processador redaction do próprio Collector. Ele cobre corpos de logs, atributos e eventos de span.

# Optional: redact at source, so these never leave your network.
# Needs the Collector's contrib distribution. A processor acts on its whole
# pipeline: every exporter in it receives the redacted record.
processors:
  redaction/vigilia:
    allow_all_keys: true
    blocked_values:
      - "[A-Z]{2}[0-9]{2}( ?[A-Z0-9]{4}){2,7}( ?[A-Z0-9]{1,3})?"   # IBANs
      - "[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}"        # email addresses
    summary: silent

service:
  pipelines:
    logs:
      processors: [redaction/vigilia]   # after the ones already here
    traces:
      processors: [redaction/vigilia]

No Lovable ou Bolt? A página do aplicativo tem um prompt que faz seu builder envolver cada edge function para você. Adicione os segredos você mesmo; nunca cole a chave em um chat.

3. Verifique se funciona

Chame sendTestError() uma vez, do mesmo import. Ele aparece como um incidente de teste sem nada para corrigir, e a página do aplicativo diz que o servidor está conectado. Erros capturados no seu próprio try/catch podem ser enviados com captureException(error, { request }).

Chamadas para IA. A linha watchAI() em cada snippet observa as chamadas do seu backend para OpenAI, Anthropic, Gemini, OpenRouter, Lovable AI e outros. Quando uma falha, o Vigilia diz o porquê em palavras simples: sem crédito (corrigido em uma página de cobrança, não no código), chave rejeitada, limites de taxa ou o provedor sobrecarregado. Ele também conta chamadas e tokens por modelo, exibidos em gráfico na página do aplicativo, e informa quando um dia chega a três vezes o seu normal: um loop ou um endpoint abusado custa dinheiro antes que qualquer coisa pareça quebrada. As respostas nunca são tocadas.

Quando as solicitações dos visitantes falham porque seu backend lançou um erro, o Vigilia vincula os dois: a solicitação falha diz "causado no seu servidor", o erro de servidor diz quem foi afetado e o diagnóstico usa ambos.

Conecte sua IA

O Vigilia é um servidor MCP, então a IA com a qual você constrói pode ler seus incidentes e corrigi-los sem copiar e colar — depois marcá-los como corrigidos, e o Vigilia confirma que a correção se manteve com tráfego real.

1. Adicione o Vigilia à sua IA com o endereço do servidor https://app.getvigilia.com/mcp.
2. Entre: sua IA abre uma página do Vigilia e você clica em Allow.
3. Pergunte: "Use o Vigilia para corrigir meu pior incidente."

A página Connect AI do painel tem os passos exatos para cada ferramenta. A versão resumida:

• Lovable: Settings → Connectors → Chat connectors → adicione um servidor MCP personalizado, escolha OAuth.
• Bolt: Connectors → Custom MCP server, transporte HTTP, escolha OAuth.
• Claude (web, desktop e mobile): Customize → Connectors → Add custom connector, depois Connect. Em um chat, ative o Vigilia em + → Connectors. Em um plano Team ou Enterprise, um Owner adiciona uma vez em Organization settings → Connectors.
• Claude Code: o plugin, que traz o servidor e dois comandos. Ou apenas o servidor: claude mcp add --transport http --scope user vigilia https://app.getvigilia.com/mcp. Depois /mcp → Authenticate.
• Cursor: um clique na página Connect AI, depois Connect em Cursor Settings → MCP.
• VS Code, Windsurf e qualquer cliente que fale HTTP streamable: adicione o endereço do servidor; eles entram da mesma forma.

Avançado

Um cliente que não consegue entrar com OAuth pode enviar um token: crie um em Settings → API tokens e envie-o como Authorization: Bearer vgs_…. A página Connect AI escreve a configuração para sua ferramenta em Advanced.

O Claude Code pergunta antes de cada chamada do Vigilia. As ferramentas do Vigilia apenas leem e atualizam seus incidentes no Vigilia, nunca seus arquivos, então você pode permiti-las em ~/.claude/settings.json. Você decide.

{
  "permissions": {
    "allow": [
      "mcp__plugin_vigilia_vigilia",
      "mcp__vigilia"
    ]
  }
}

O que sua IA pode fazer

• list_open_incidents, get_incident — o que está quebrado, do pior primeiro, com a explicação simples, as evidências e o prompt de correção.
• mark_fixed, get_fix_status — feche o ciclo: o Vigilia observa o tráfego real e relata se a correção se manteve.
• list_apps, get_app_health, get_install_instructions, check_install — incluindo instalar o Vigilia em um novo projeto.
• get_server_install_instructions — configurar erros de servidor no backend do projeto (Pro).

Cada ferramenta apenas lê, exceto mark_fixed, que marca um incidente como corrigido no Vigilia e inicia a observação da correção. Nada toca seu código, a menos que sua IA seja um agente de codificação trabalhando no seu projeto, e então é sua IA fazendo a mudança, na sua frente. Escolha Read only na página de entrada do Vigilia e ela pode olhar, mas nunca marcar nada.

Coisas para perguntar

• "O que está quebrado no meu aplicativo agora?": os incidentes abertos, do pior primeiro.
• "Explique meu pior incidente do Vigilia e como corrigi-lo.": a explicação simples, as evidências e o prompt de correção.
• "Use o Vigilia para corrigir meu pior incidente.": em um agente de codificação com seu projeto aberto, ele corrige a causa e, depois que você fizer o deploy, marca como corrigido.
• "Minha última correção se manteve?": se o tráfego real confirmou.
• "Como está meu aplicativo hoje?": uptime, incidentes abertos e tráfego de hoje.
• "Instale o Vigilia neste projeto.": a tag de script no lugar certo, depois uma verificação do site ao vivo.

Desconectando

Remova o Vigilia nas configurações de conectores da sua IA e desconecte-o no Vigilia em Settings → Connected AI, onde cada IA que você conectou está listada.

Se algo não funcionar

• A conexão ou a entrada falha. Verifique se o endereço é exatamente https://app.getvigilia.com/mcp e se você está conectado à conta do Vigilia que deseja na página que abre. Remover o conector e adicioná-lo novamente inicia uma entrada limpa.
• "You already have 10 Vigilia tokens". Uma conta mantém 10 conexões e tokens de API juntos. Desconecte o que você não usa mais em Settings → Connected AI (ou revogue um token em API tokens) e conecte novamente.
• "Vigilia is connected read-only". Foi permitido com Read only. Desconecte o Vigilia nas configurações de conectores da sua IA, conecte novamente e mantenha Read & write para permitir que ele marque incidentes como corrigidos.
• Sem aplicativos ou sem incidentes. Nada pode estar quebrado, ou o Vigilia pode não estar instalado ainda: pergunte "verifique minha instalação do Vigilia" ou abra a página do aplicativo no painel.
• "Too many requests". Contas gratuitas têm 2.000 solicitações de API e MCP por dia, redefinidas à meia-noite UTC. Um agente corrigindo um bug usa algumas dezenas.

Ainda preso? Envie um e-mail para support@getvigilia.com com o que você perguntou e o que viu.

Plugin do Claude Code

O plugin agrupa o servidor MCP com dois comandos: /vigilia:fix (corrija seu pior incidente, adicione um teste de regressão onde o repositório tem testes e depois marque como corrigido) e /vigilia:install (adicione o Vigilia a um projeto, CSP incluído). No Claude Code:

/plugin marketplace add https://getvigilia.com/claude/marketplace.json
/plugin install vigilia@vigilia

Depois entre uma vez: digite /mcp, escolha plugin:vigilia:vigilia e Authenticate (se disser desabilitado, escolha Enable primeiro), depois clique em Allow na página do Vigilia que abre.

O plugin traz o servidor do Vigilia com ele: não o adicione também com claude mcp add, ou o Claude verá cada ferramenta duas vezes.

API REST

Os mesmos dados que sua IA vê, para seus próprios scripts. URL base https://app.getvigilia.com/v1; envie seu token como Authorization: Bearer vgs_…. O contrato completo está em openapi.json.

curl -H "Authorization: Bearer vgs_…" "https://app.getvigilia.com/v1/incidents?status=open"

• Incidents — listar, ler (com evidências), resolver, ignorar, reabrir.
• Apps — listar, saúde, executar a verificação de instalação.
• Deploys — POST /v1/apps/{appId}/deploys com um rótulo (uma versão ou commit) do CI. O Vigilia também percebe deploys por conta própria; um marcador adiciona seu rótulo e o tempo exato.

Os limites de taxa são por token e por plano: 60 solicitações por minuto no Free, 300 no Pro, 600 no Team. Contas gratuitas também têm 2.000 solicitações de API e MCP por dia, todos os tokens juntos, redefinidas à meia-noite UTC. Um agente corrigindo um bug usa algumas dezenas.

Marcadores de deploy do CI

Vigilia detecta novas versões por conta própria. Um marcador adiciona o commit, então um incidente diz "Começou 12 minutos após o seu deploy (3f9c2a1)". Salve um token de leitura e escrita como o segredo de CI VIGILIA_TOKEN, e adicione um passo após o seu deploy. No GitHub Actions:

- name: Tell Vigilia about this deploy
  continue-on-error: true
  env:
    VIGILIA_TOKEN: ${{ secrets.VIGILIA_TOKEN }}
  run: |
    curl -fsS -X POST "https://app.getvigilia.com/v1/apps/YOUR_APP_ID/deploys" \
      -H "Authorization: Bearer $VIGILIA_TOKEN" \
      -H "Content-Type: application/json" \
      -d "{\"label\": \"${GITHUB_SHA::7}\"}"

Em qualquer outro lugar, execute isto após o deploy:

curl -fsS -X POST "https://app.getvigilia.com/v1/apps/YOUR_APP_ID/deploys" \
  -H "Authorization: Bearer $VIGILIA_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"label\": \"$(git rev-parse --short HEAD)\"}" || true

A página de cada aplicativo no painel tem esses passos em Marcar deploys do CI, com o ID preenchido. Um POST com falha nunca falha o deploy.

Webhooks

Nos planos pagos, o Vigilia pode enviar um POST de cada alerta para o seu próprio endpoint — para PagerDuty, Zapier, Make, n8n ou seu próprio código. Adicione um em Configurações → Canais de alerta; você recebe um segredo de assinatura (whsec_…) uma única vez.

Eventos: incident.opened, app.down, app.recovered, fix.verified e test do botão "Enviar teste". Cada corpo contém id, type, createdAt e app; incidentes carregam a explicação simples, o prompt de correção e um link. Quando uma das páginas extras do aplicativo cai em vez do aplicativo inteiro, o endpoint do incidente a nomeia, e o app.recovered a carrega em recovery.endpoint.

Verificar a assinatura

Vigilia-Signature: t=<unix seconds>,v1=<hex HMAC-SHA256>, calculado sobre t.rawBody com o seu segredo. Use o corpo bruto e rejeite qualquer coisa com mais de 5 minutos:

import { createHmac, timingSafeEqual } from 'node:crypto';

export function verifyVigilia(rawBody, header, secret) {
  const { t, v1 } = Object.fromEntries(header.split(',').map((p) => p.split('=')));
  if (Math.abs(Date.now() / 1000 - Number(t)) > 300) return false;
  const expected = createHmac('sha256', secret).update(\`${t}.${rawBody}\`).digest('hex');
  return v1?.length === expected.length && timingSafeEqual(Buffer.from(expected), Buffer.from(v1));
}

Repetições

Responda com qualquer 2xx dentro de 8 segundos. Em um 5xx, 429 ou timeout, o Vigilia repete após 2 minutos, 10 minutos, 30 minutos e 2 horas; outro 4xx significa que a URL está errada e ele para. Após 10 falhas seguidas, o canal se desativa sozinho e informa isso em Configurações.

Rastreadores de problemas

No plano Team, o Vigilia abre um problema para um incidente no GitHub Issues, Linear ou Jira Cloud. O problema carrega a explicação simples, quem foi afetado, as evidências e o stack, o que o visitante fez, o prompt de correção e um link de volta. Abra um pela página do incidente com Criar problema, ou deixe o Vigilia abrir para incidentes críticos (ou altos e críticos) por conta própria. Um incidente recebe no máximo um problema.

Conecte um rastreador em Configurações → Rastreadores de problemas com um token que você cria:

• GitHub: um token de granularidade fina com acesso a um único repositório e Issues: Leitura e escrita.
• Linear: uma chave de API pessoal e a chave da equipe (ENG em ENG-123).
• Jira Cloud: um token de API da Atlassian, o e-mail da conta, seu site …atlassian.net e a chave do projeto. Problemas abrem como Bug ou como Tarefa quando o projeto não tem Bug.

O Vigilia verifica se consegue alcançar o rastreador antes de salvá-lo, e Testar verifica novamente sem abrir um problema. O token é mantido no servidor e nunca é mostrado novamente.

Sentry

Já usa Sentry? Mantenha-o. No plano Team, o Vigilia lê cada novo problema do Sentry em erro ou fatal, explica em linguagem simples com um prompt de correção para o seu builder e publica de volta no problema do Sentry como comentário e nos seus alertas do Vigilia. O agrupamento do Sentry é mantido: um problema do Sentry, um incidente do Vigilia, diagnosticado uma vez.

1. No Vigilia, Configurações → Sentry → Conectar Sentry: escolha o aplicativo e sua organização do Sentry. Você recebe uma URL de webhook.
2. No Sentry, Configurações → Configurações de desenvolvedor → Integrações personalizadas → Criar nova integração → Integração interna. Cole a URL do webhook, dê a ela Problema e Evento: Leitura e Escrita e marque o webhook de problema.
3. Cole o token da integração e o segredo do cliente de volta no Vigilia. O Vigilia verifica o token antes de salvar e verifica a assinatura de cada webhook.

Até 300 problemas do Sentry por mês por conexão. O incidente linka para o problema do Sentry, e o comentário do Sentry linka de volta.

Páginas de status e o selo

A partir da página de qualquer aplicativo, publique uma página de status pública em getvigilia.com/status/your-app: se está no ar agora, 90 dias de uptime e indisponibilidade recente. Ela mostra apenas uptime — nunca erros ou qualquer coisa sobre seus visitantes.

A página vem com um selo para o seu site ou README, que linka para ela:

[![Monitored by Vigilia](https://getvigilia.com/badge/your-app.svg)](https://getvigilia.com/status/your-app)

O que o Vigilia monitora

Sinal	O que se torna um incidente
Erros	Quedas, rejeições de promessas não tratadas e erros de console de visitantes reais — agrupados, então mil do mesmo erro são um incidente.
Requisições com falha	Requisições à sua API ou serviços que falham. Vários hosts falhando ao mesmo tempo é a conexão de um visitante, não seu aplicativo, e é ignorado. Um "não encontrado" (404) espera até 3 visitantes diferentes o acessarem: um geralmente é uma página pedindo algo que não existe, e dizendo isso.
Requisições lentas	Requisições que levam mais de 5 segundos, uma vez que 3 visitantes diferentes as acessaram.
Cliques de raiva	Alguém clicando na mesma coisa 3 vezes em um segundo — um botão que parece morto — uma vez que 3 visitantes diferentes fizeram isso.
Uptime	Seu aplicativo não respondendo, verificado a cada minuto nos planos pagos e a cada 5 no Free. Nos planos pagos, também as páginas-chave que você adiciona (checkout, login, uma API), cada uma com texto que deve exibir, então uma página que carrega mas está quebrada também conta.
Erros de servidor	Erros que seu backend lança ou responde (5xx), de @getvigilia/server. Pro.
Lentidões	Seu aplicativo respondendo de repente várias vezes mais devagar do que o normal, julgado contra sua própria velocidade usual.
Verificações de saúde	Chaves secretas visíveis no seu código público (semanal), seu certificado de segurança (diário) e o registro do seu domínio expirando (semanal).
Velocidade da página	Velocidade de carregamento, responsividade e estabilidade visual (LCP, INP, CLS), na aba Desempenho do aplicativo.

E contexto em cada incidente: quando um problema começou logo após um deploy, quando um serviço do qual seu aplicativo depende — Supabase, Vercel, OpenAI e outros — estava tendo uma indisponibilidade própria naquele momento e, com erros de servidor ativados, quando uma requisição falhando nos navegadores dos visitantes foi causada por um erro que seu backend lançou. Esses dois incidentes apontam um para o outro.

Erros do seu próprio laptop e de links de pré-visualização são registrados, mas nunca alertados. Os erros que os aplicativos mais enfrentam são explicados na biblioteca de erros.

Como uma correção é confirmada

Quando você marca um incidente como corrigido, o Vigilia continua monitorando. Um erro que permanece ausente só prova algo se era esperado aparecer novamente, então uma correção é confirmada por tráfego, não apenas por tempo.

• A taxa anterior. Nos 7 dias antes de você marcar como corrigido, quantas visitas o erro atingiu, de quantas visitas ao seu aplicativo?
• As visitas desde então. Nessa taxa, quantas vezes o erro teria aparecido até agora se a correção não tivesse feito nada?
• Confirmado em 3. Uma vez que pelo menos 3 eram esperados e nenhum veio, e 24 horas se passaram, você recebe "Sua correção funcionou". Com 3 esperados, uma correção que não fez nada ficaria quieta cerca de 1 vez em 20.

Um erro que atingiu 1 visita em 10 precisa de cerca de 30 visitas para confirmar; um que atingiu todas as visitas precisa de 3. Visitas da sua própria máquina ou de um link de pré-visualização não contam.

Tráfego insuficiente

Se poucas pessoas usam o aplicativo, o Vigilia diz "Tráfego insuficiente para confirmar esta correção ainda" e mostra quantas visitas viu e aproximadamente quantas mais precisa. Ele continua monitorando por 7 dias. Se o tráfego nunca vier, ele encerra o monitoramento como tráfego insuficiente e avisa uma vez por e-mail. Isso não é uma correção falha. Significa que o Vigilia não conseguiu distinguir uma correção de uma semana tranquila e não vai afirmar o contrário.

Se voltar

O incidente reabre imediatamente, marcado como regressão, independentemente do que o monitoramento concluiu.

Erros do seu backend (erros de servidor e OpenTelemetry) não podem ser confirmados dessa forma ainda: o Vigilia vê as requisições que falham, não as que têm sucesso, então não tem tráfego para contar. As correções deles leem "tráfego insuficiente" após 7 dias, a menos que o erro retorne. Pela API e MCP, o mesmo veredito é fix.watch, com os números em fix.evidence.