Cloudflare Issues Detecção de Erros em Tempo Real Que Alimenta Seu Agente de IA

O problema é a cola manual

Agentes de código já consultam dados de observabilidade, navegam pelo repositório, alteram código, escrevem testes e abrem um PR. O que eles não fazem sozinhos é perceber que 400 falhas com request IDs diferentes vêm do mesmo bug, e montar logs, traces e a versão do Worker num contexto coerente. Esse handoff ainda é uma pessoa copiando stack trace pra dentro de um chat.

A Cloudflare está fechando essa lacuna com o Issues — monitoramento de erros nativo para Workers, agora em beta aberto. Ele agrupa exceções repetidas, respostas 5xx e logs de erro em uma única issue, e empurra esse contexto direto pro agente configurado. Resultado: menos passos manuais entre "quebrou" e "aqui está o pull request".

Se você quer entender por que workflows agênticos viraram item obrigatório nas empresas, dá uma olhada no nosso artigo sobre como agentes de IA estão redefinindo a integração corporativa.

Ativando o Issues com uma linha

Sem SDK, sem wrapper, sem pacote de instrumentação. O Issues roda dentro do runtime do Workers. Adiciona isso no seu wrangler.jsonc:

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

Com isso ligado, o runtime captura:

• Exceções não tratadas e invocações que falharam
• Respostas HTTP 5xx
• Saída de console.log() e console.error()
• Logs que contêm stack trace
• Condições de alarme descontroladas e loops que geram muito log

Falhas repetidas da mesma causa raiz são agrupadas numa issue única, com timestamp da primeira ocorrência, contagem e tendência de frequência.

Adicionando contexto com OpenTelemetry

A Cloudflare sabe o que aconteceu dentro do Worker, mas não pra quem. Usa a API de OpenTelemetry embutida — sem instalar nada — pra anexar identificadores de usuário, conta e sessão:

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;

Esses atributos viajam com cada ocorrência. Quando uma issue dispara, você consegue ver se as falhas estão concentradas numa conta ou sessão antes de escalar.

Ligando o Issues ao seu agente

O Issues não fica só no dashboard. Com Automations, você define um gatilho (limite de ocorrências, ou issue que volta depois de um período quieto) e um destino:

O payload inclui a exceção, stack trace com source map, logs e traces antes e depois, versão do Worker e os atributos customizados que você adicionou. Pra investigação mais profunda, conecta o agente ao Cloudflare MCP pra ele consultar logs e traces relacionados direto.

Validação no mundo real

A Cloudflare rodou o Issues no próprio serviço de Workflows (apps de longa duração e múltiplos passos em cima do Workers). Em um dia com o negócio ligado, pegaram dois bugs de edge case escondidos no meio de tráfego pesado: uma migration travada num loop de retry de foreign key do SQLite, e um processo de deleção que estourava o limite de subrequests do Workers e nunca terminava. Os dois foram roteados automaticamente pra um agente que rastreou os erros até o código do Workflows e propôs correções.

Pontos de atenção

• Beta aberto significa que a API e a config de automação podem mudar. Não constrói alerta crítico só em cima do Issues ainda.
• Heurística de agrupamento não é perfeita. Bugs distintos com stack trace parecido podem se fundir; causas diferentes com exceção idêntica podem não se separar direito.
• Saída do agente ainda precisa de review. O PR que ele abre é ponto de partida, não botão de merge. Revisão humana do fix e do deploy continua sendo sua.
• Contexto só é bom se você anexar. Sem atributos OpenTelemetry, o agente vê a falha mas não o raio de impacto.

Se você também curte acompanhar os sinais da indústria em torno de IA, nosso artigo sobre pegadinhas de April Fools na tech e o que deu errado é um bom lembrete de que hype e substância nem sempre andam juntos.

Próximos passos

1. Liga observability.issues.enabled como true no seu wrangler.jsonc.
2. Adiciona atributos OpenTelemetry pros identificadores que seu time realmente usa no triage (user, account, tenant, session).
3. Configura uma Automation pra um agente de não-produção primeiro — observa o que ele propõe antes de apontar pra prod.
4. Usa o cf CLI pra inspecionar issues e criar automações via script se você gerencia muitos Workers.

Pra aprofundar: estuda a API de tracing OpenTelemetry do Workers, lê sobre o Cloudflare MCP pra consulta do lado do agente, e testa source maps pra que os stack traces resolvam pro seu TypeScript, não pro bundle final. O ganho real não é a detecção — é o handoff estruturado da falha até o fix. É essa parte que a maioria dos times ainda faz na mão.