Vigilia

Vigilia observa tu aplicación en vivo, explica cada problema en lenguaje sencillo y escribe el prompt de corrección. Tu IA lo corrige; Vigilia lo confirma con tráfico real.

Ver en getvigilia.com

Documentación

Configurar Vigilia

Una etiqueta de script para empezar. Todo lo demás — tu IA, alertas, la API — es opcional y toma un minuto cada cosa.

Instalar

Añade tu aplicación en el panel y mostrará esta etiqueta con tu clave completada. Va en el <head> de cada página:

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

Dónde va, según el framework:

FrameworkDónde va la etiqueta
HTML planoPega la etiqueta dentro de <head> de cada página HTML (normalmente solo index.html), antes de </head>.
Vite, Lovable, Bolt, la mayoría de apps ReactPega la etiqueta dentro de <head> de index.html en la raíz del proyecto (Lovable, Bolt y la mayoría de apps React/Vite).
Next.js (app router)En app/layout.tsx, renderiza <Script src="…" data-key="…" strategy="afterInteractive" /> (de next/script) dentro de <body>, conservando cada atributo data- que tenga la etiqueta. vigilia.js encuentra su propia etiqueta incluso cuando se inyecta después de la carga.
Next.js (pages router)En pages/_document.tsx, añade la etiqueta dentro de <Head> (de next/document), conservando cada atributo data- que tenga.
SvelteKitPega la etiqueta dentro de <head> de src/app.html, antes de %sveltekit.head%.
AstroPega la etiqueta dentro de <head> de tu layout compartido (p. ej. src/layouts/Layout.astro), con is:inline para que Astro no la modifique.
RemixEn app/root.tsx, añade la etiqueta dentro de <head>, después de <Links />.
NuxtEn nuxt.config, añádela bajo app.head.script como { src, "data-key": …, defer: true }, más "data-endpoint" si la etiqueta lo tiene.

¿Construido con un generador de IA? No la pegues tú mismo: el panel te da un prompt que le dice a Lovable, Bolt, Cursor o Claude Code exactamente qué añadir — y qué no tocar.

O instalar desde npm

¿Escribiendo el código tú mismo, con un bundler? El mismo SDK está en npm como @getvigilia/browser. Úsalo en lugar de la etiqueta, no ambos; el panel rellena tu clave.

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' });

Integrado en tu app, solo necesita la línea connect-src de abajo.

Si tu sitio tiene una Content-Security-Policy

Solo entonces: añade estas dos direcciones a las directivas que ya tienes. Conserva todo lo demás.

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

Un script bloqueado es la razón más común por la que una instalación nueva no muestra nada. La comprobación de instalación en la página de la app lee tu sitio en vivo y te dice si esto es lo que está pasando.

Opcional: apuntar a la línea exacta

Publica source maps y Vigilia resuelve un fallo en tu bundle minificado a tu propio archivo y línea (src/pages/Checkout.tsx:42), en el incidente y en el prompt de corrección. Solo los obtiene mientras diagnostica. En Vite, build.sourcemap: 'hidden' los escribe sin apuntar la página hacia ellos. En Next.js es productionBrowserSourceMaps: true.

Comprobar que funciona

Publica, luego abre tu app con ?vigilia_test=1 en la dirección (la página de configuración tiene el enlace listo). Vigilia envía un error de prueba claramente etiquetado y un primer incidente aparece en segundos. Nada en tu página se rompe.

Errores de servidor

Los errores en tu backend (una edge function de Supabase, una ruta API de Next.js, un Cloudflare Worker) nunca llegan al navegador del visitante, así que el script no puede verlos. @getvigilia/server los envía a Vigilia, donde se convierten en incidentes como cualquier otro: en lenguaje sencillo, con un prompt de corrección para tu generador. Son solo errores (sin tracing, sin logs), no tiene dependencias y nunca lanza excepciones en tu código. Los errores de servidor son parte de Pro.

1. Dos secretos

En la página de tu app, bajo Errores de servidor, crea una clave de servidor. Se muestra una sola vez. Configúrala junto con el endpoint donde corre tu backend, nunca en código:

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

2. Envuelve tus handlers

Un handler envuelto reporta cualquier cosa que lance, y cualquier 5xx que devuelva, con el texto de error de un cuerpo como { "error": "…" }. La respuesta en sí nunca se toca.

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

En Supabase: Project Settings → Edge Functions → Secrets, o con 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
});

En Vercel: Project → Settings → Environment Variables, para Production. Localmente, en .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 secretos de Worker: ejecuta npx wrangler secret put VIGILIA_SERVER_KEY, luego lo mismo 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());

En las variables de entorno de tu host (o un archivo .env que tu app cargue).

¿Ya usas OpenTelemetry? (Team)

No se necesita paquete: añade Vigilia como un exportador más. Tus traces y logs siguen yendo a donde van hoy; Vigilia conserva solo excepciones y logs de ERROR, y descarta el resto al llegar. OTLP sobre HTTP, codificación 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>

Redactar en el origen (opcional). Vigilia limpia cada registro al llegar: correos, tokens, números tipo tarjeta y números de cuenta bancaria (IBANs). Con OpenTelemetry esa es la única limpieza que recibe un registro, porque sale de tu red tal como se registró. Para redactar antes de que salga, añade el procesador redaction del propio Collector. Cubre cuerpos de logs, atributos y 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]

¿En Lovable o Bolt? La página de la app tiene un prompt que hace que tu generador envuelva cada edge function por ti. Añade los secretos tú mismo; nunca pegues la clave en un chat.

3. Comprobar que funciona

Llama a sendTestError() una vez, desde el mismo import. Aparece como un incidente de prueba sin nada que corregir, y la página de la app dice que el servidor está conectado. Los errores capturados en tu propio try/catch se pueden enviar con captureException(error, { request }).

Llamadas a IA. La línea watchAI() en cada fragmento observa las llamadas de tu backend a OpenAI, Anthropic, Gemini, OpenRouter, Lovable AI y otros. Cuando una falla, Vigilia dice por qué en palabras sencillas: sin crédito (se arregla en una página de facturación, no en código), una clave rechazada, límites de tasa, o el proveedor sobrecargado. También cuenta llamadas y tokens por modelo, graficados en la página de la app, y te avisa cuando un día llega a tres veces tu habitual: un bucle o un endpoint abusado cuesta dinero antes de que nada parezca roto. Las respuestas nunca se tocan.

Cuando las peticiones de los visitantes fallan porque tu backend lanzó una excepción, Vigilia vincula ambas: la petición fallida dice "causado en tu servidor", el error de servidor dice a quién afectó, y el diagnóstico usa ambos.

Conecta tu IA

Vigilia es un servidor MCP, así que la IA con la que construyes puede leer tus incidentes y corregirlos sin copiar y pegar — luego marcarlos como corregidos, y Vigilia confirma que la corrección se mantuvo con tráfico real.

  1. Añade Vigilia a tu IA con la dirección del servidor https://app.getvigilia.com/mcp.
  2. Inicia sesión: tu IA abre una página de Vigilia, y haces clic en Permitir.
  3. Pregunta: "Usa Vigilia para corregir mi peor incidente."

La página Conectar IA del panel tiene los pasos exactos para cada herramienta. La versión corta:

  • Lovable: Settings → Connectors → Chat connectors → añade un servidor MCP personalizado, elige OAuth.
  • Bolt: Connectors → Custom MCP server, transporte HTTP, elige OAuth.
  • Claude (web, escritorio y móvil): Customize → Connectors → Add custom connector, luego Connect. En un chat, activa Vigilia desde + → Connectors. En un plan Team o Enterprise, un Owner lo añade una vez en Organization settings → Connectors.
  • Claude Code: el plugin, que trae el servidor y dos comandos. O solo el servidor: claude mcp add --transport http --scope user vigilia https://app.getvigilia.com/mcp. Luego /mcp → Authenticate.
  • Cursor: un clic desde la página Conectar IA, luego Connect en Cursor Settings → MCP.
  • VS Code, Windsurf y cualquier cliente que hable HTTP streamable: añade la dirección del servidor; inician sesión de la misma manera.

Avanzado

Un cliente que no puede iniciar sesión con OAuth puede enviar un token en su lugar: crea uno en Settings → API tokens y envíalo como Authorization: Bearer vgs_…. La página Conectar IA escribe la configuración para tu herramienta bajo Advanced.

Claude Code pregunta antes de cada llamada a Vigilia. Las herramientas de Vigilia solo leen y actualizan tus incidentes en Vigilia, nunca tus archivos, así que puedes permitirlas en ~/.claude/settings.json. Tú decides.

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

Lo que tu IA puede hacer

  • list_open_incidents, get_incident — qué está roto, peor primero, con la explicación sencilla, la evidencia y el prompt de corrección.
  • mark_fixed, get_fix_status — cierra el ciclo: Vigilia observa tráfico real y reporta si la corrección se mantuvo.
  • list_apps, get_app_health, get_install_instructions, check_install — incluyendo instalar Vigilia en un proyecto nuevo.
  • get_server_install_instructions — configurar errores de servidor en el backend del proyecto (Pro).

Cada herramienta solo lee, excepto mark_fixed, que marca un incidente como corregido en Vigilia e inicia la vigilancia de la corrección. Nada toca tu código a menos que tu IA sea un agente de codificación trabajando en tu proyecto, y entonces es tu IA haciendo el cambio, frente a ti. Elige Read only en la página de inicio de sesión de Vigilia y podrá mirar pero nunca marcar nada.

Cosas para preguntar

  • "¿Qué está roto en mi app ahora mismo?": los incidentes abiertos, peor primero.
  • "Explica mi peor incidente de Vigilia y cómo corregirlo.": la explicación sencilla, la evidencia y el prompt de corrección.
  • "Usa Vigilia para corregir mi peor incidente.": en un agente de codificación con tu proyecto abierto, corrige la causa y, una vez que hayas desplegado, lo marca como corregido.
  • "¿Mi última corrección se mantuvo?": si el tráfico real lo confirmó.
  • "¿Cómo está mi app hoy?": tiempo de actividad, incidentes abiertos y tráfico de hoy.
  • "Instala Vigilia en este proyecto.": la etiqueta de script en el lugar correcto, luego una comprobación del sitio en vivo.

Desconectar

Elimina Vigilia en la configuración de conectores de tu IA, y desconéctalo en Vigilia bajo Settings → Connected AI, donde se lista cada IA que has conectado.

Si algo no funciona

  • La conexión o el inicio de sesión falla. Comprueba que la dirección es exactamente https://app.getvigilia.com/mcp, y que has iniciado sesión en la cuenta de Vigilia que quieres en la página que se abre. Eliminar el conector y añadirlo de nuevo inicia un inicio de sesión limpio.
  • "You already have 10 Vigilia tokens". Una cuenta tiene 10 conexiones y tokens de API juntos. Desconecta lo que ya no uses en Settings → Connected AI (o revoca un token en API tokens), luego conecta de nuevo.
  • "Vigilia is connected read-only". Se permitió con Read only. Desconecta Vigilia en la configuración de conectores de tu IA, conecta de nuevo y mantén Read & write para permitirle marcar incidentes como corregidos.
  • Sin apps o sin incidentes. Puede que nada esté roto, o que Vigilia aún no esté instalado: pregunta "comprueba mi instalación de Vigilia", o abre la página de la app en el panel.
  • "Too many requests". Las cuentas gratuitas tienen 2,000 peticiones de API y MCP al día, que se reinician a medianoche UTC. Un agente corrigiendo un bug usa unas pocas docenas.

¿Sigue atascado? Envía un correo a support@getvigilia.com con lo que preguntaste y lo que viste.

Plugin de Claude Code

El plugin incluye el servidor MCP con dos comandos: /vigilia:fix (corrige tu peor incidente, añade una prueba de regresión donde el repositorio tenga pruebas, luego márcalo como corregido) y /vigilia:install (añade Vigilia a un proyecto, CSP incluido). En Claude Code:

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

Luego inicia sesión una vez: escribe /mcp, elige plugin:vigilia:vigilia y Authenticate (si dice deshabilitado, elige Enable primero), luego haz clic en Permitir en la página de Vigilia que se abre.

El plugin trae el servidor de Vigilia consigo: no lo añadas también con claude mcp add, o Claude verá cada herramienta dos veces.

API REST

Los mismos datos que ve tu IA, para tus propios scripts. URL base https://app.getvigilia.com/v1; envía tu token como Authorization: Bearer vgs_…. El contrato completo está en openapi.json.

curl -H "Authorization: Bearer vgs_…" "https://app.getvigilia.com/v1/incidents?status=open"
  • Incidentes — listar, leer (con evidencia), resolver, ignorar, reabrir.
  • Apps — listar, salud, ejecutar la comprobación de instalación.
  • Despliegues — POST /v1/apps/{appId}/deploys con una etiqueta (una versión o commit) desde CI. Vigilia también nota los despliegues por sí mismo; un marcador añade tu etiqueta y el momento exacto.

Los límites de tasa son por token y por plan: 60 peticiones por minuto en Free, 300 en Pro, 600 en Team. Las cuentas gratuitas también tienen 2,000 peticiones de API y MCP al día, todos los tokens juntos, reiniciadas a medianoche UTC. Un agente corrigiendo un bug usa unas pocas docenas.

Marcadores de despliegue desde CI

Vigilia detecta nuevas versiones por sí solo. Un marcador añade el commit, de modo que un incidente dice "Comenzó 12 minutos después de tu despliegue (3f9c2a1)". Guarda un token de lectura y escritura como secreto de CI VIGILIA_TOKEN, y luego añade un paso después de tu despliegue. En 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}\"}"

En cualquier otro lugar, ejecuta esto después de desplegar:

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

La página de cada aplicación en el panel tiene estos pasos bajo Marcar despliegues desde CI, con su ID ya completado. Un POST fallido nunca hace fallar el despliegue.

Webhooks

En los planes de pago, Vigilia puede enviar por POST cada alerta a tu propio endpoint — para PagerDuty, Zapier, Make, n8n o tu propio código. Añade uno en Configuración → Canales de alerta; recibes un secreto de firma (whsec_…) una sola vez.

Eventos: incident.opened, app.down, app.recovered, fix.verified y test desde el botón "Enviar prueba". Cada cuerpo incluye id, type, createdAt y app; los incidentes llevan la explicación en lenguaje sencillo, la sugerencia de corrección y un enlace. Cuando una de las páginas adicionales de la aplicación cae en lugar de toda la aplicación, el endpoint del incidente la nombra, y app.recovered la incluye en recovery.endpoint.

Verificar la firma

Vigilia-Signature: t=<unix seconds>,v1=<hex HMAC-SHA256>, calculado sobre t.rawBody con tu secreto. Usa el cuerpo sin procesar y rechaza cualquier cosa con más de 5 minutos de antigüedad:

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));
}

Reintentos

Responde con cualquier 2xx dentro de 8 segundos. Ante un 5xx, 429 o tiempo de espera agotado, Vigilia reintenta después de 2 minutos, 10 minutos, 30 minutos y 2 horas; otro 4xx significa que la URL es incorrecta y se detiene. Después de 10 fallos consecutivos, el canal se desactiva solo y lo indica en Configuración.

Seguimiento de incidencias

En el plan Team, Vigilia abre una incidencia para un incidente en GitHub Issues, Linear o Jira Cloud. La incidencia incluye la explicación en lenguaje sencillo, quién está afectado, la evidencia y el stack, lo que hizo el visitante, la sugerencia de corrección y un enlace de vuelta. Abre una desde la página del incidente con Crear incidencia, o deja que Vigilia las abra automáticamente para incidentes críticos (o altos y críticos). Un incidente recibe como máximo una incidencia.

Conecta un seguimiento en Configuración → Seguimiento de incidencias con un token que crees:

  • GitHub: un token de grano fino con acceso al repositorio único, e Issues: Lectura y escritura.
  • Linear: una clave de API personal y la clave del equipo (ENG en ENG-123).
  • Jira Cloud: un token de API de Atlassian, el correo de la cuenta, tu sitio …atlassian.net y la clave del proyecto. Las incidencias se abren como Bug, o como Tarea cuando el proyecto no tiene Bug.

Vigilia comprueba que puede alcanzar el seguimiento antes de guardarlo, y Probar lo comprueba de nuevo sin abrir una incidencia. El token se guarda en el servidor y nunca se vuelve a mostrar.

Sentry

¿Ya usas Sentry? Consérvalo. En el plan Team, Vigilia lee cada nueva incidencia de Sentry en nivel error o fatal, la explica en lenguaje sencillo con una sugerencia de corrección para tu builder, y publica eso de vuelta en la incidencia de Sentry como comentario, y en tus alertas de Vigilia. Se mantiene la agrupación de Sentry: una incidencia de Sentry, un incidente de Vigilia, diagnosticado una vez.

  1. En Vigilia, Configuración → Sentry → Conectar Sentry: elige la aplicación y tu organización de Sentry. Recibes una URL de webhook.
  2. En Sentry, Configuración → Configuración de desarrollador → Integraciones personalizadas → Crear nueva integración → Integración interna. Pega la URL del webhook, dale Issue & Event: Read & Write y marca el webhook de issue.
  3. Pega el token de la integración y el secreto de cliente de vuelta en Vigilia. Vigilia comprueba el token antes de guardarlo y verifica la firma de cada webhook.

Hasta 300 incidencias de Sentry al mes por conexión. El incidente enlaza a la incidencia de Sentry, y el comentario de Sentry enlaza de vuelta.

Páginas de estado y la insignia

Desde la página de cualquier aplicación, publica una página de estado pública en getvigilia.com/status/your-app: si está activa ahora mismo, 90 días de tiempo de actividad y caídas recientes. Muestra solo tiempo de actividad — nunca errores ni nada sobre tus visitantes.

La página incluye una insignia para tu sitio o README, que enlaza a ella:

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

Lo que Vigilia vigila

SeñalQué se convierte en incidente
ErroresFallos, rechazos de promesas no controlados y errores de consola de visitantes reales — agrupados, de modo que mil del mismo error son un solo incidente.
Solicitudes fallidasSolicitudes a tu API o servicios que fallan. Varios hosts fallando a la vez es la conexión del visitante, no tu aplicación, y se ignora. Un "no encontrado" (404) espera hasta que 3 visitantes distintos lo hayan encontrado: normalmente uno es una página que pide algo que no existe, y lo dice.
Solicitudes lentasSolicitudes que tardan más de 5 segundos, una vez que 3 visitantes distintos las han encontrado.
Clics de furiaAlguien haciendo clic en lo mismo 3 veces en un segundo — un botón que parece muerto — una vez que 3 visitantes distintos lo han hecho.
Tiempo de actividadTu aplicación no responde, comprobado cada minuto en planes de pago y cada 5 en el plan Free. En planes de pago, también las páginas clave que añadas (pago, inicio de sesión, una API), cada una con texto que debe mostrar, de modo que una página que carga pero está rota también cuenta.
Errores de servidorErrores que tu backend lanza o responde (5xx), desde @getvigilia/server. Pro.
RalentizacionesTu aplicación respondiendo de repente varias veces más lento de lo habitual, juzgado contra su propia velocidad normal.
Comprobaciones de saludClaves secretas visibles en tu código público (semanal), tu certificado de seguridad (diario) y la caducidad del registro de tu dominio (semanal).
Velocidad de páginaVelocidad de carga, capacidad de respuesta y estabilidad visual (LCP, INP, CLS), en la pestaña Rendimiento de la aplicación.

Y contexto en cada incidente: cuando un problema comenzó justo después de un despliegue, cuando un servicio del que depende tu aplicación — Supabase, Vercel, OpenAI y otros — estaba sufriendo una caída propia en ese momento, y, con errores de servidor activados, cuando una solicitud que fallaba en los navegadores de los visitantes fue causada por un error que tu backend lanzó. Esos dos incidentes se señalan mutuamente.

Los errores desde tu propio portátil y desde enlaces de vista previa se registran pero nunca se alertan. Los errores que más afectan a las aplicaciones se explican en la biblioteca de errores.

Cómo se confirma una corrección

Cuando marcas un incidente como corregido, Vigilia sigue vigilando. Un error que desaparece solo prueba algo si debía reaparecer, así que una corrección se confirma por tráfico, no solo por tiempo.

  • La tasa anterior. En los 7 días antes de marcarlo como corregido, ¿a cuántas visitas afectó el error, de cuántas visitas a tu aplicación?
  • Las visitas desde entonces. A esa tasa, ¿cuántas veces habría aparecido el error hasta ahora si la corrección no hubiera hecho nada?
  • Confirmado en 3. Una vez que al menos 3 eran esperables y no llegó ninguna, y han pasado 24 horas, recibes "Tu corrección funcionó". Con 3 esperables, una corrección que no hizo nada permanecería en silencio aproximadamente 1 de cada 20 veces.

Un error que afectó a 1 visita de cada 10 necesita unas 30 visitas para confirmarse; uno que afectó a cada visita necesita 3. Las visitas desde tu propia máquina o un enlace de vista previa no cuentan.

Tráfico insuficiente

Si muy poca gente usa la aplicación, Vigilia dice "Aún no hay suficiente tráfico para confirmar esta corrección" y muestra cuántas visitas ha visto y aproximadamente cuántas más necesita. Sigue vigilando durante 7 días. Si el tráfico nunca llega, cierra la vigilancia como tráfico insuficiente y te lo comunica una vez por correo. Eso no es una corrección fallida. Significa que Vigilia no pudo distinguir una corrección de una semana tranquila, y no afirmará lo contrario.

Si reaparece

El incidente se reabre de inmediato, marcado como regresión, sea cual sea la conclusión de la vigilancia.

Los errores de tu backend (errores de servidor y OpenTelemetry) aún no pueden confirmarse de esta manera: Vigilia ve las solicitudes que fallan, no las que tienen éxito, así que no tiene tráfico que contar. Sus correcciones se leen como "tráfico insuficiente" después de 7 días a menos que el error regrese. A través de la API y MCP, el mismo veredicto es fix.watch, con los números en fix.evidence.