debug-issue-with-datadog

Start with intake: fetch the Linear or GitHub issue, extract the subsystem, region, time window, and project IDs. Then run a broad Datadog sweep of APM spans, logs, and metrics across both EU and US, cluster errors by projectId and message, and map each cluster to handler files in the repo.

Worker async jobs emit spans named 'process <queue-name>' via instrumentAsync wrappers. The repo debug map lists each subsystem's queue file, handler directory, and span resource name, so you can filter APM with service:worker and the matching resource_name.

Yes. Two Datadog MCP servers are used, one for datadoghq.eu and one for datadoghq.com, and queries run against both unless intake clearly localizes the incident. Regional disparity between prod-eu and prod-us is checked first since it often rules hypotheses in or out.

Do not use it when the task is implementing a known fix rather than investigating what is broken. Implementation tasks should go to backend development guidelines or the relevant package guide instead of an investigative telemetry sweep.

Common causes are a wrong case-sensitive resource name, a time window that misses when the issue fired, or querying the wrong regional MCP server. Tenant tags may also live on the api-auth-verify child span rather than the request root span, requiring correlation by trace ID.