Skip to content
Back to skills

Api Latency Investigation

ASecurity

Use when performing api latency investigation — provides a systematic investigation framework for diagnosing and resolving API latency issues. Covers distributed tracing analysis, bottleneck identification across the request path, database query impact, external dependency latency, and optimization recommendations with expected impact.

  • 6 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added September 8, 2026
devopsgorailsapidatabaseperformance

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add cloudthinker-ai/CloudSkills --skill api-latency-investigation --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Api Latency Investigation?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Api Latency Investigation
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/cloudthinker-ai-api-latency-investigation/badge)](https://www.skillsdirectory.com/skills/cloudthinker-ai-api-latency-investigation)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: api-latency-investigation
enabled: true
description: |
  Use when performing api latency investigation — provides a systematic
  investigation framework for diagnosing and resolving API latency issues.
  Covers distributed tracing analysis, bottleneck identification across the
  request path, database query impact, external dependency latency, and
  optimization recommendations with expected impact.
required_connections:
  - prefix: apm
    label: "APM / Tracing Platform"
  - prefix: monitoring
    label: "Monitoring Platform"
config_fields:
  - key: api_endpoint
    label: "Affected API Endpoint(s)"
    required: true
    placeholder: "e.g., GET /api/v1/orders, POST /api/v1/checkout"
  - key: current_latency
    label: "Current P95 Latency"
    required: true
    placeholder: "e.g., 2500ms"
  - key: target_latency
    label: "Target P95 Latency"
    required: false
    placeholder: "e.g., 500ms"
features:
  - PERFORMANCE
  - API
  - INVESTIGATION
---

# API Latency Investigation

## Phase 1: Symptom Characterization
1. Define the latency problem precisely
   - [ ] Which endpoints are affected?
   - [ ] When did latency increase? (gradual or sudden)
   - [ ] Is it constant or intermittent?
   - [ ] Does it correlate with traffic volume?
   - [ ] Which percentiles are affected? (P50, P95, P99)
   - [ ] Are specific users, regions, or clients affected?
2. Collect current latency metrics
3. Compare against historical baseline
4. Check for recent deployments or infrastructure changes

### Latency Profile

| Endpoint | P50 (current) | P50 (baseline) | P95 (current) | P95 (baseline) | P99 (current) |
|----------|-------------|---------------|-------------|---------------|-------------|
|          | ms          | ms            | ms          | ms            | ms          |

## Phase 2: Request Path Analysis
1. Trace the full request path
   - [ ] Client / CDN / Load Balancer
   - [ ] API Gateway / Reverse Proxy
   - [ ] Application server processing
   - [ ] Database queries
   - [ ] Cache lookups (hit/miss)
   - [ ] External API calls
   - [ ] Message queue operations
   - [ ] Response serialization
2. Measure time spent at each component using distributed tracing
3. Identify the component consuming most time

### Latency Breakdown

| Component | Avg Time (ms) | % of Total | Variance | Bottleneck |
|-----------|-------------|-----------|----------|------------|
| Network/LB | | % | Low/High | [ ] |
| API Gateway | | % | | [ ] |
| App processing | | % | | [ ] |
| Database | | % | | [ ] |
| Cache | | % | | [ ] |
| External APIs | | % | | [ ] |
| Serialization | | % | | [ ] |
| **Total** | | **100%** | | |

## Phase 3: Bottleneck Deep Dive
1. For database bottlenecks:
   - [ ] Review slow queries and execution plans
   - [ ] Check for missing indexes
   - [ ] Analyze connection pool utilization
   - [ ] Check for lock contention
2. For application bottlenecks:
   - [ ] Profile CPU hotspots
   - [ ] Check for memory pressure / GC pauses
   - [ ] Review thread/goroutine blocking
   - [ ] Check for synchronous operations that should be async
3. For external dependency bottlenecks:
   - [ ] Measure dependency response times
   - [ ] Check for timeout configurations
   - [ ] Evaluate circuit breaker behavior
   - [ ] Consider caching dependency responses
4. For network bottlenecks:
   - [ ] Check DNS resolution times
   - [ ] Verify TLS handshake performance
   - [ ] Measure cross-AZ/region latency
   - [ ] Review connection reuse and keep-alive settings

## Phase 4: Root Cause Identification
1. Correlate latency with system metrics
2. Check for resource saturation (CPU, memory, connections, IOPS)
3. Review application logs for errors and warnings
4. Identify any cascade effects from downstream services
5. Document confirmed root cause(s)

### Root Cause Analysis

| Root Cause | Evidence | Impact on Latency | Fix Complexity | Priority |
|-----------|----------|-------------------|---------------|----------|
|           |          | +ms              | Low/Med/High  | 1-5      |

## Phase 5: Optimization Implementation
1. Implement fixes in priority order
   - [ ] Database query optimization and indexing
   - [ ] Caching layer (application cache, Redis, CDN)
   - [ ] Connection pooling tuning
   - [ ] Async processing for non-critical paths
   - [ ] Payload size reduction
   - [ ] Batch/bulk API operations
   - [ ] Circuit breakers for external dependencies
2. Test each fix and measure latency impact
3. Verify no regressions introduced

## Phase 6: Validation & Monitoring
1. Compare post-fix latency against baseline
2. Validate across all affected percentiles
3. Run load test at peak traffic levels
4. Set up latency alerting and SLO monitoring
5. Document findings for future reference

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |

## Output Format
- **Latency Profile**: Current vs. baseline by percentile
- **Request Path Breakdown**: Time per component analysis
- **Root Cause Report**: Confirmed causes with evidence
- **Optimization Results**: Before/after latency measurements
- **Monitoring Setup**: Alerts and dashboards for ongoing tracking

## Action Items
- [ ] Characterize the latency problem with precise metrics
- [ ] Trace request path and identify bottleneck components
- [ ] Deep dive into top bottleneck(s)
- [ ] Implement optimizations in priority order
- [ ] Validate latency improvement against targets
- [ ] Set up ongoing latency monitoring and alerting

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

View all in devops →

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.