Response time monitoring

Severity: Recommended

Check automatically:

1. Look for APM/monitoring integration:

# Check for monitoring env vars
grep -riE "datadog|newrelic|new_relic|prometheus|grafana|sentry.*dsn|apm" .env.example .env* 2>/dev/null

# Look for timing/metrics middleware
grep -riE "responseTime|request.duration|metrics|histogram|latency" --include="*.ts" --include="*.js" src/ lib/ app/ 2>/dev/null | head -20

# Check for prometheus metrics endpoint
grep -riE "/metrics|prom-client|prometheus" --include="*.ts" --include="*.js" src/ lib/ app/ 2>/dev/null | head -10

2. Check for monitoring config files:

# Look for APM config
ls -la datadog.yaml newrelic.js prometheus.yml grafana/ monitoring/ 2>/dev/null

# Check package.json for monitoring packages
grep -E "datadog|newrelic|prom-client|@sentry/.*tracing" package.json 2>/dev/null

3. If monitoring tool identified, verify endpoint-level visibility:
   • Request dashboard access or URL
   • Confirm response times are graphed per endpoint (not just aggregate)
   • Check that slowest endpoints are identifiable

If not found in code, ask user:

• "What monitoring tool do you use for request performance?"
• "Can you share the dashboard URL for response time graphs?"

Cross-reference with:

• MON-001 (Section 12 - infrastructure monitoring)

Pass criteria:

• Monitoring solution configured and active
• Response time graphs available per endpoint
• Can identify top slowest endpoints from the tool

Fail criteria:

• No response time monitoring configured
• Only aggregate metrics (no per-endpoint breakdown)
• Monitoring configured but not deployed/active

Warning (not a fail):

• Any endpoint averaging >500ms response time - flag for optimization review

Evidence to capture:

• Monitoring tool name and version
• Dashboard URL (if external)
• Screenshot or list of top 5 slowest endpoints with avg response times

---