Cloudflare Issues Detección de Errores en Tiempo Real Que Alimenta a Tu Agente de IA

El problema es el pegamento manual

Los agentes de código ya consultan datos de observabilidad, navegan el repo, cambian código, escriben tests y abren un PR. Lo que no hacen solos es darse cuenta de que 400 fallos con request IDs distintos vienen del mismo bug, y armar logs, traces y la versión del Worker en un contexto coherente. Ese handoff todavía es una persona copiando el stack trace a un chat.

Cloudflare está cerrando ese hueco con Issues — monitoreo de errores nativo para Workers, ahora en beta abierta. Agrupa excepciones repetidas, respuestas 5xx y logs de error en un solo issue, y empuja ese contexto directo al agente configurado. Resultado: menos pasos manuales entre "se rompió" y "aquí está el pull request".

Si quieres entender por qué los workflows agénticos ya son obligatorios en las empresas, checa nuestro análisis sobre cómo los agentes de IA están redefiniendo la integración empresarial.

Activando Issues con una línea

Sin SDK, sin wrapper, sin paquete de instrumentación. Issues vive dentro del runtime de Workers. Agrega esto a tu wrangler.jsonc:

{
  "observability": {
    "issues": {
      "enabled": true
    }
  }
}

Con eso activado, el runtime captura:

• Excepciones no capturadas e invocaciones fallidas
• Respuestas HTTP 5xx
• Salida de console.log() y console.error()
• Logs que contienen stack trace
• Condiciones de alarma descontroladas y loops que generan mucho log

Los fallos repetidos de la misma causa raíz se agrupan en un solo issue, con timestamp de primera aparición, conteo y tendencia de frecuencia.

Agregando contexto con OpenTelemetry

Cloudflare sabe qué pasó dentro del Worker, pero no a quién. Usa la API de OpenTelemetry integrada — sin instalar nada — para pegar identificadores de usuario, cuenta y sesión:

import { tracing } from "cloudflare:workers";

export default {
  async fetch(request: Request): Promise<Response> {
    const { userId, accountId, sessionId } = await getAuthDetails(request);
    const span = tracing.getActiveSpan();
    span?.setAttribute("user.id", userId);
    span?.setAttribute("account.id", accountId);
    span?.setAttribute("session.id", sessionId);

    return handleRequest(request);
  },
} satisfies ExportedHandler;

Esos atributos viajan con cada ocurrencia. Cuando un issue se dispara, puedes ver si los fallos se concentran en una cuenta o sesión antes de escalar.

Conectando Issues a tu agente

Issues no se queda solo en el dashboard. Con Automations, defines un trigger (umbral de ocurrencias, o issue que regresa después de un periodo tranquilo) y un destino:

El payload incluye la excepción, stack trace con source map, logs y traces antes y después, la versión del Worker y los atributos custom que hayas agregado. Para investigación más profunda, conecta el agente a Cloudflare MCP para que consulte logs y traces relacionados directo.

Validación en el mundo real

Cloudflare corrió Issues contra su propio servicio de Workflows (apps de larga duración y múltiples pasos sobre Workers). En un día con la cosa prendida, encontraron dos bugs de edge case escondidos entre tráfico pesado: una migración atorada en un loop de retry de foreign key de SQLite, y un proceso de borrado que se pasaba del límite de subrequests de Workers y nunca terminaba. Los dos se enrutaron automáticamente a un agente que rastreó los errores hasta el código de Workflows y propuso fixes.

Puntos a tener en cuenta

• Beta abierta significa que la API y la config de automatización pueden cambiar. No armes alertas críticas solo con Issues todavía.
• La heurística de agrupación no es perfecta. Bugs distintos con stack trace parecido se pueden fusionar; causas distintas con excepción idéntica pueden no separarse bien.
• La salida del agente todavía requiere review. El PR que abre es punto de partida, no botón de merge. La revisión humana del fix y del deploy sigue siendo tuya.
• El contexto solo sirve si lo agregas. Sin atributos OpenTelemetry, el agente ve el fallo pero no el radio de impacto.

Si también te gusta seguir las señales de la industria alrededor de IA, nuestro artículo sobre bromas de April Fools en tech y lo que salió mal es un buen recordatorio de que el hype y la sustancia no siempre van de la mano.

Siguientes pasos

1. Pon observability.issues.enabled en true en tu wrangler.jsonc.
2. Agrega atributos OpenTelemetry para los identificadores que tu equipo realmente usa en triage (user, account, tenant, session).
3. Configura una Automation hacia un agente de no-producción primero — observa qué propone antes de apuntarlo a prod.
4. Usa el cf CLI para inspeccionar issues y crear automatizaciones por script si manejas muchos Workers.

Para profundizar: estudia la API de tracing OpenTelemetry de Workers, lee sobre Cloudflare MCP para consultas del lado del agente, y experimenta con source maps para que los stack traces resuelvan a tu TypeScript, no al bundle final. La ganancia real no es la detección — es el handoff estructurado del fallo al fix. Esa parte la mayoría de los equipos todavía la hace a mano.