Monitoring APIs
Overview
Build real-time API monitoring with metrics collection (request rate, latency percentiles, error rates), health check endpoints, and alerting rules. Instrument API middleware to emit Prometheus metrics or StatsD counters, configure Grafana dashboards with SLO tracking, and implement synthetic monitoring probes for uptime verification.
Prerequisites
- Prometheus + Grafana stack, or Datadog/New Relic/CloudWatch for metrics and dashboards
- Metrics client library:
prom-client (Node.js), prometheus_client (Python), or Micrometer (Java)
- Alerting channel configured: PagerDuty, Slack webhook, or email for alert routing
- Structured logging library: Winston, Pino (Node.js), structlog (Python), or Logback (Java)
- Synthetic monitoring tool: Checkly, Uptime Robot, or custom cron-based health probes
Instructions
- Examine existing middleware and logging setup using Grep and Read to identify current observability coverage and gaps.
- Implement metrics middleware that records per-request data:
http_request_duration_seconds histogram (with method, path, status labels), http_requests_total counter, and http_requests_in_flight gauge.
- Create a
/health endpoint returning structured health status including dependency checks (database connectivity, cache availability, external service reachability) with response time for each.
- Add a
/ready endpoint separate from health that returns 503 during startup initialization and graceful shutdown, for load balancer integration.
- Configure histogram buckets aligned with SLO targets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10] seconds for comprehensive latency distribution.
- Build Grafana dashboard panels: request rate (QPS), p50/p95/p99 latency, error rate percentage, active connections, and per-endpoint breakdown.
- Define alerting rules: error rate > 5% for 5 minutes (critical), p99 latency > 2s for 10 minutes (warning), health check failure for 3 consecutive probes (critical).
- Implement synthetic monitoring that sends periodic requests to critical endpoints from external locations, measuring availability and latency from the consumer perspective.
- Add SLO tracking with error budget calculation: define SLO (99.9% availability, p95 < 500ms), compute burn rate, and alert when error budget consumption exceeds projected pace.
See ${CLAUDE_SKILL_DIR}/references/implementation.md for the full implementation guide.
Output
${CLAUDE_SKILL_DIR}/src/middleware/metrics.js - Prometheus metrics collection middleware${CLAUDE_SKILL_DIR}/src/routes/health.js - Health check and readiness endpoints${CLAUDE_SKILL_DIR}/monitoring/dashboards/ - Grafana dashboard JSON definitions${CLAUDE_SKILL_DIR}/monitoring/alerts/ - Alerting rule definitions (Prometheus AlertManager or Grafana)${CLAUDE_SKILL_DIR}/monitoring/synthetic/ - Synthetic monitoring probe scripts${CLAUDE_SKILL_DIR}/monitoring/slo.yaml - SLO definitions and error budget configuration
Error Handling
| Error |
Cause |
Solution |
| Metrics cardinality explosion |
High-cardinality labels (user ID, request ID) on metrics |
Use bounded label values only (method, status code, endpoint group); aggregate user-level data in logs |
| Health check false positive |
Health endpoint returns 200 but dependent service is degraded |
Include dependency checks with individual status; use structured response with degraded state |
| Alert fatigue |
Too many low-severity alerts firing during normal operations |
Tune alert thresholds using historical baselines; implement alert grouping and deduplication |
| Dashboard data gap |
Metrics not collected during deployment rollout window |
Configure Prometheus scrape interval < deployment duration; use push-based metrics during deploys |
| SLO miscalculation |
Error budget calculation uses wrong time window or includes planned maintenance |
Exclude maintenance windows from SLO calculation; align window with business reporting period |
Refer to ${CLAUDE_SKILL_DIR}/references/errors.md for comprehensive error patterns.
Examples
RED method dashboard: Request rate, Error rate, and Duration panels per endpoint, with drill-down from overview to individual endpoint detail, including top-10 slowest endpoints by p99.
SLO-based alerting: Define 99.9% availability SLO with 30-day rolling window, alert when 1-hour burn rate exceeds 14.4x (consuming daily error budget in 1 hour), with PagerDuty escalation.
Dependency health matrix: Dashboard showing real-time health status of all downstream dependencies (database, cache, external APIs) with latency sparklines and circuit breaker state indicators.
See ${CLAUDE_SKILL_DIR}/references/examples.md for additional examples.
Resources
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: jeremylongshore-claude-code-plugins-plus-skills-monitoring-a3description: Monitoring APIs4---5# Monitoring APIs67## Overview89Build real-time API monitoring with metrics collection (request rate, latency percentiles, error rates), health check endpoints, and alerting rules. Instrument API middleware to emit Prometheus metrics or StatsD counters, configure Grafana dashboards with SLO tracking, and implement synthetic monitoring probes for uptime verification.1011## Prerequisites1213- Prometheus + Grafana stack, or Datadog/New Relic/CloudWatch for metrics and dashboards14- Metrics client library: `prom-client` (Node.js), `prometheus_client` (Python), or Micrometer (Java)15- Alerting channel configured: PagerDuty, Slack webhook, or email for alert routing16- Structured logging library: Winston, Pino (Node.js), structlog (Python), or Logback (Java)17- Synthetic monitoring tool: Checkly, Uptime Robot, or custom cron-based health probes1819## Instructions20211. Examine existing middleware and logging setup using Grep and Read to identify current observability coverage and gaps.222. Implement metrics middleware that records per-request data: `http_request_duration_seconds` histogram (with method, path, status labels), `http_requests_total` counter, and `http_requests_in_flight` gauge.233. Create a `/health` endpoint returning structured health status including dependency checks (database connectivity, cache availability, external service reachability) with response time for each.244. Add a `/ready` endpoint separate from health that returns 503 during startup initialization and graceful shutdown, for load balancer integration.255. Configure histogram buckets aligned with SLO targets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10] seconds for comprehensive latency distribution.266. Build Grafana dashboard panels: request rate (QPS), p50/p95/p99 latency, error rate percentage, active connections, and per-endpoint breakdown.277. Define alerting rules: error rate > 5% for 5 minutes (critical), p99 latency > 2s for 10 minutes (warning), health check failure for 3 consecutive probes (critical).288. Implement synthetic monitoring that sends periodic requests to critical endpoints from external locations, measuring availability and latency from the consumer perspective.299. Add SLO tracking with error budget calculation: define SLO (99.9% availability, p95 < 500ms), compute burn rate, and alert when error budget consumption exceeds projected pace.3031See `${CLAUDE_SKILL_DIR}/references/implementation.md` for the full implementation guide.3233## Output3435- `${CLAUDE_SKILL_DIR}/src/middleware/metrics.js` - Prometheus metrics collection middleware36- `${CLAUDE_SKILL_DIR}/src/routes/health.js` - Health check and readiness endpoints37- `${CLAUDE_SKILL_DIR}/monitoring/dashboards/` - Grafana dashboard JSON definitions38- `${CLAUDE_SKILL_DIR}/monitoring/alerts/` - Alerting rule definitions (Prometheus AlertManager or Grafana)39- `${CLAUDE_SKILL_DIR}/monitoring/synthetic/` - Synthetic monitoring probe scripts40- `${CLAUDE_SKILL_DIR}/monitoring/slo.yaml` - SLO definitions and error budget configuration4142## Error Handling4344| Error | Cause | Solution |45|-------|-------|----------|46| Metrics cardinality explosion | High-cardinality labels (user ID, request ID) on metrics | Use bounded label values only (method, status code, endpoint group); aggregate user-level data in logs |47| Health check false positive | Health endpoint returns 200 but dependent service is degraded | Include dependency checks with individual status; use structured response with `degraded` state |48| Alert fatigue | Too many low-severity alerts firing during normal operations | Tune alert thresholds using historical baselines; implement alert grouping and deduplication |49| Dashboard data gap | Metrics not collected during deployment rollout window | Configure Prometheus scrape interval < deployment duration; use push-based metrics during deploys |50| SLO miscalculation | Error budget calculation uses wrong time window or includes planned maintenance | Exclude maintenance windows from SLO calculation; align window with business reporting period |5152Refer to `${CLAUDE_SKILL_DIR}/references/errors.md` for comprehensive error patterns.5354## Examples5556**RED method dashboard**: Request rate, Error rate, and Duration panels per endpoint, with drill-down from overview to individual endpoint detail, including top-10 slowest endpoints by p99.5758**SLO-based alerting**: Define 99.9% availability SLO with 30-day rolling window, alert when 1-hour burn rate exceeds 14.4x (consuming daily error budget in 1 hour), with PagerDuty escalation.5960**Dependency health matrix**: Dashboard showing real-time health status of all downstream dependencies (database, cache, external APIs) with latency sparklines and circuit breaker state indicators.6162See `${CLAUDE_SKILL_DIR}/references/examples.md` for additional examples.6364## Resources6566- Google SRE Book: Monitoring Distributed Systems chapter67- Prometheus documentation: https://prometheus.io/docs/68- Grafana dashboards: https://grafana.com/docs/grafana/latest/69- USE Method and RED Method for metrics design7071---72> Converted and distributed by [TomeVault](https://tomevault.io/claim/jeremylongshore) — claim your Tome and manage your conversions.73<!-- tomevault:4.0:skill_md:2026-04-11 -->
tomevault-io