Render Monitor

Render Metrics Interpretation Guide

Comprehensive guide to understanding and acting on Render service metrics.

Available Metrics

CPU Metrics

cpu_usage

What it measures: Percentage of allocated CPU being used.

Interpret CPU utilization relative to the service's selected compute plan and workload. Use compute-plans.md when current CPU specifications matter instead of inferring them from legacy plan names.

Actions for high CPU:

1. Profile code for inefficient operations

2. Add caching for repeated computations

3. Optimize database queries

4. Upgrade to a larger compute plan

5. Enable autoscaling

cpu_limit

What it measures: Maximum CPU allocated to the service.

Use case: Compare cpu_usage to cpu_limit to determine if throttling is occurring.

Formula: throttle_risk = cpu_usage / cpu_limit

• >0.9 = High throttling risk

• >0.8 = Moderate risk

• <0.7 = Safe

Memory Metrics

memory_usage

What it measures: Memory being used by the service in bytes.

Interpret memory relative to the resource's reported limit rather than mapping legacy plan names to memorized byte values. Use compute-plans.md when current memory specifications matter.

Actions for high memory:

1. Profile for memory leaks

2. Reduce in-memory caching

3. Process data in streams/chunks

4. Optimize data structures

5. Upgrade plan

memory_limit

What it measures: Maximum memory allocated.

OOM Risk Formula: oom_risk = memory_usage / memory_limit

• >0.95 = Imminent OOM

• >0.90 = High risk

• >0.80 = Moderate risk

• <0.70 = Safe

HTTP Metrics

http_latency

What it measures: Response time at a given percentile.

Common quantiles:

• 0.5 (p50/median) - Typical user experience

• 0.95 (p95) - Most users' worst experience

• 0.99 (p99) - Tail latency, outliers

Healthy latency targets:

Actions for high latency:

1. Add database indexes

2. Implement caching with Key Value

3. Optimize N+1 queries

4. Use connection pooling

5. Add CDN for static assets

6. Scale horizontally

http_request_count

What it measures: Number of HTTP requests received.

Use cases:

• Detect traffic spikes

• Correlate with error rates

• Capacity planning

• Usage billing estimation

Aggregation options:

• By host - Traffic per domain

• By statusCode - Success vs error rates

Calculating error rate:

error_rate = (5xx_requests / total_requests) * 100

Target: <0.1% error rate

Instance Metrics

instance_count

What it measures: Number of running service instances.

Interpreting changes:

• Increasing: Autoscaling up (good if traffic increasing)

• Decreasing: Autoscaling down (cost optimization)

• Fluctuating: Possible instability or aggressive scaling

• Stuck at 1: May not have autoscaling enabled

Autoscaling health check: Compare instance_count trends with cpu_usage and http_request_count:

• CPU high + instances not scaling = Check autoscaling config

• Instances scaling + latency still high = Hit max instances or DB bottleneck

Database Metrics

active_connections

What it measures: Number of active database connections.

Connection limits vary by Postgres compute plan. Fetch the current limit through compute-plans.md, then compare active connections with that limit.

Actions for high connections:

1. Implement connection pooling (PgBouncer)

2. Close idle connections

3. Reduce connection timeouts

4. Fix connection leaks in code

5. Upgrade the database compute plan

Database CPU/Memory

Same interpretation as service metrics, but:

• High CPU often indicates slow queries

• High memory often indicates large result sets or missing indexes

Bandwidth Metrics

bandwidth_usage

What it measures: Network data transfer (egress).

Considerations:

• Spikes correlate with large responses or file downloads

• Sustained high bandwidth may indicate inefficient API design

• Consider compression (gzip/brotli) to reduce bandwidth

Cost implications:

• Render includes bandwidth in plans

• Usage beyond the included allowance can incur additional cost; confirm current details at Render pricing

Time-Based Analysis

Choosing Time Ranges

Correlating Events

When investigating issues, align metrics with:

1. Deploy times (list_deploys)

2. Error log timestamps (list_logs)

3. Traffic patterns (http_request_count)

4. External events (marketing campaigns, etc.)

Alert Thresholds Recommendations

Critical Alerts (Immediate Action)

Warning Alerts (Investigate Soon)

Metric Query Examples

Service Health Dashboard

# CPU trend
get_metrics(resourceId: "<id>", metricTypes: ["cpu_usage"], resolution: 300)

# Memory trend
get_metrics(resourceId: "<id>", metricTypes: ["memory_usage"], resolution: 300)

# Request rate
get_metrics(resourceId: "<id>", metricTypes: ["http_request_count"], resolution: 60)

# Latency percentiles
get_metrics(resourceId: "<id>", metricTypes: ["http_latency"], httpLatencyQuantile: 0.5)
get_metrics(resourceId: "<id>", metricTypes: ["http_latency"], httpLatencyQuantile: 0.95)
get_metrics(resourceId: "<id>", metricTypes: ["http_latency"], httpLatencyQuantile: 0.99)

Capacity Planning

# Peak CPU over last 24h
get_metrics(
  resourceId: "<id>",
  metricTypes: ["cpu_usage"],
  cpuUsageAggregationMethod: "MAX",
  startTime: "<24-hours-ago>",
  resolution: 3600
)

# Peak memory over last 24h
get_metrics(
  resourceId: "<id>",
  metricTypes: ["memory_usage"],
  startTime: "<24-hours-ago>",
  resolution: 3600
)

# Traffic patterns
get_metrics(
  resourceId: "<id>",
  metricTypes: ["http_request_count"],
  startTime: "<7-days-ago>",
  resolution: 3600
)

Database Performance

# Connection usage
get_metrics(
  resourceId: "<postgres-id>",
  metricTypes: ["active_connections"],
  startTime: "<1-hour-ago>"
)

# Database CPU (indicates query load)
get_metrics(
  resourceId: "<postgres-id>",
  metricTypes: ["cpu_usage"],
  startTime: "<1-hour-ago>"
)