ar-dd-api-performance

Scan Datadog APM traffic to detect slow APIs and maintain per-endpoint optimization reports.

1|2|Updated Jul 11, 2026
One-click install
npx skills add https://github.com/mahsanamin/agentic-repos --skill ar-dd-api-performance-mahsanamin
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ar-dd-api-performance
Source: https://github.com/mahsanamin/agentic-repos/tree/main/skills/ar-dd-api-performance
Command: npx skills add https://github.com/mahsanamin/agentic-repos --skill ar-dd-api-performance-mahsanamin

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Slow or error-prone API endpoints often go unnoticed until users complain, and manually digging through Datadog traces to find and explain bottlenecks is repetitive work. This Skill automates the sweep: it discovers which APIs were hit in a time window, flags the ones breaching latency or error thresholds, explains why they are slow by cross-referencing traces with the repository's code, and keeps one living report file per API per environment. ## Core Features & Use Cases - Automated traffic discovery and gating: Aggregates Datadog spans by resource name, computes p50/p95/error rates, and flags APIs exceeding configurable thresholds (default p95 > 200ms or error rate ≥ 5%). - Trace-to-code root cause analysis: Samples representative traces per flagged API, builds a time breakdown of internal calls, and maps each bottleneck to a concrete code site using a heuristics catalog (cache bypass, N+1, sequential calls, and more). - Idempotent living reports: Maintains fingerprinted per-API Markdown reports with a four-status taxonomy and append-only History, rewriting files only when findings genuinely change, plus a worst-first per-environment index. - Use Case: Schedule a daily run against production to continuously track slow endpoints; each morning the team gets updated report files committed and pushed to the findings repository, with History rows explaining what improved or regressed. ## Quick Start Ask the assistant to run an API performance scan of this service and update the performance reports for the last day of production traffic.

Frequently Asked Questions about ar-dd-api-performance

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find slow API endpoints in Datadog automatically?▼

Run an API performance scan, which aggregates Datadog server spans over a configurable window (default last day), computes p50/p95 latency and error rates per endpoint, and flags any API exceeding the thresholds. Flagged APIs get sampled traces and a written root-cause report.

How does the scan explain why an API is slow?▼

It samples representative traces per flagged endpoint, builds a breakdown of child spans grouped by service and operation, then maps each significant group to a code site in the working tree. A heuristics catalog identifies patterns like bypassed caches, N+1 queries, and sequential outbound calls.

Can I run the performance scan on staging instead of production?▼

Yes, pass a session-only override such as env=staging when invoking the scan. Reports are written under a separate Staging directory with its own index, and the override is never persisted to skill.config, so production defaults stay intact.

Why does a repeated scan not rewrite the report files?▼

Each report stores a fingerprint computed from status, bucketed p95, bottleneck set, and finding IDs. If the fingerprint is unchanged, the file is left byte-identical and only the environment index records the verification, keeping daily runs noise-free.

What happens if the Datadog MCP is not connected?▼

The scan stops immediately with a clear message at the prerequisite check. This is deliberate for scheduled loops: a headless run without the MCP fails loudly instead of silently producing empty reports or orphan directories.

What are the limitations of single-trace performance findings?▼

Cache and repetition heuristics are never confirmed from one trace, since a single request cannot distinguish a legitimate cache miss from a bypassed cache. Low-traffic endpoints are marked low-confidence and suspicions are recorded as hypotheses to re-check on busier windows.