TempsTemps
On this page
  1. Real-time metrics
  2. Accessing metrics
  3. Understanding metrics
  4. Health checks
  5. Monitoring best practices
  6. Troubleshooting

Monitoring

Temps collects CPU, memory, network, and request metrics for every deployed container — no external monitoring service needed. Get real-time visibility into health and performance, configure health checks, and set alert thresholds directly from the dashboard.

Real-time metrics

Temps provides real-time metrics for every deployed container, giving you instant visibility into your application's performance.

Available metrics:

  • Requests - Total requests and request rate
  • Response Time - Average response time in ms
  • CPU Usage - Percentage of CPU resources used
  • Memory Usage - RAM consumption in MB and percentage
  • Network I/O - Inbound and outbound data transfer rate

Metrics update in real-time, so you always see current performance data.

Accessing metrics

  1. 1

    Go to Projects and open your project.

  2. 2

    Select the Monitoring tab to view live CPU and memory metrics.

Via Dashboard

  1. Go to Projects → Select your project
  2. Click the Monitoring tab
  3. View real-time metrics: requests, response time, CPU, memory, and network I/O

The monitoring dashboard shows:

  • Requests - Total requests over time with request rate
  • Response Time - Average response time graph
  • CPU - Live CPU usage percentage
  • Memory - Live memory usage in MB and percentage
  • Network I/O - Real-time inbound/outbound data transfer

For deeper distributed tracing on top of these metrics, see OpenTelemetry (OTLP) Ingest & Query.

Via API

Access metrics programmatically using the API:

# Get real-time metrics for an environment
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "https://your-temps-instance.com/api/projects/{project_id}/environments/{environment_id}/metrics"

The API returns:

{
  "requests_total": 1523,
  "requests_rate": 12.5,
  "response_time_avg_ms": 45,
  "cpu_percent": 47.0,
  "cpu_utilization_percent": 23.5,
  "memory_bytes": 268435456,
  "memory_percent": 52.0,
  "network_rx_bytes_per_sec": 1024,
  "network_tx_bytes_per_sec": 2048
}

cpu_percent is the raw Docker per-core value (100% = 1 core). For a container with a 2-core CPU limit, this can reach 200%. cpu_utilization_percent is normalized to the container's CPU limit (0–100%), where 100% means the container is fully using its entire allocation. Use cpu_utilization_percent for alerting and threshold comparisons.

Understanding metrics

Requests

Tracks the total number of requests and request rate over time.

Watch for:

  • Sudden spikes in traffic
  • Unusually high error rates
  • Request rate exceeding expected capacity

Actions: monitor traffic patterns and scale resources if needed.

Response time

Tracks the average time to process requests in milliseconds.

Watch for:

  • Values consistently above 500ms, which may indicate performance issues
  • Sudden spikes in response time

Actions: optimize application code, add caching, review database queries, or consider scaling.

CPU usage

Two CPU metrics are available. cpu_percent is the raw Docker per-core value where 100% equals one full CPU core — a container with a 2-core limit can legitimately read 200% at full utilization. cpu_utilization_percent is normalized relative to the container's CPU limit: 0% means idle, 100% means the container is fully consuming its entire CPU allocation, regardless of how many cores that represents.

Watch for:

  • cpu_utilization_percent consistently above 80%
  • Sustained cpu_utilization_percent at or near 100%, which indicates you need more CPU allocation

Do not use raw cpu_percent thresholds for alerting — on a multi-core container a flat 90% threshold fires far too early.

Actions: increase CPU allocation in project settings, optimize application code, or add caching to reduce computation.

Memory usage

Tracks RAM consumption in bytes and as a percentage of allocated memory.

Watch for:

  • Usage approaching 90% of allocated memory
  • Memory usage continuously growing (potential memory leak)
  • Container restarts due to OOM (Out of Memory) errors

Actions: increase memory allocation or investigate memory leaks in your code.

Network I/O

Tracks data transfer rates (inbound and outbound) in bytes per second.

Watch for:

  • Unusual spikes in traffic
  • Asymmetric patterns (high outbound, low inbound)
  • Network saturation
  • Sudden massive spikes that may indicate a DDoS attack
  • Unusual outbound patterns that may indicate data exfiltration

Health checks

  1. 1

    Open Project Settings then Deployment.

  2. 2

    Configure the Health Check path and interval.

Configure health checks to automatically monitor your application's availability:

Setting up health checks

Health checks are configured in your project's deployment settings:

  1. Go to Project Settings → Deployment
  2. Configure Health Check settings:
    • Path: Endpoint to check (e.g., /health or /api/health)
    • Interval: How often to check (default: 30 seconds)
    • Timeout: Maximum wait time (default: 5 seconds)
    • Retries: Number of failed attempts before marking unhealthy

Health check endpoint

Your application should expose a health check endpoint that returns quickly:

// Express.js example
app.get("/health", (req, res) => {
  res.status(200).json({ status: "ok", timestamp: Date.now() });
});

# Flask example
@app.route('/health')
def health():
    return {'status': 'ok', 'timestamp': time.time()}, 200

Keep health checks lightweight. They should verify basic application state (database connectivity, critical services) but avoid expensive operations.

Monitoring best practices

Set resource limits

Configure appropriate CPU and memory limits based on your application's needs, then monitor actual usage and adjust over time.

How to set limits:

  1. Go to Project Settings → Deployment → Resources
  2. Set CPU (millicores) and Memory (MB)
  3. Monitor for a few days
  4. Adjust based on actual usage patterns

Look at trends, not just point-in-time values:

  • Gradual memory increases indicate memory leaks
  • CPU spikes during specific times reveal traffic patterns
  • Network anomalies can signal security issues

Set up alerts

Configure alerts for critical thresholds:

  • container.cpu_utilization_percent greater than 80% for 5 minutes — this is relative to the container's CPU limit and safe to compare against a flat percentage
  • Do not alert on raw container.cpu_percent greater than 90% — a 2-core container at full utilization reads 200%, so a 90% threshold fires at roughly 45% of actual capacity
  • Memory greater than 85% of allocation
  • Container restarts
  • Health check failures

Alerts can notify you via email, webhooks, or integrations.

Compare environments

Compare metrics across environments to identify issues:

  • Production vs staging performance
  • Preview environment resource usage
  • Before/after deployment comparisons

Troubleshooting

High CPU usage

Symptom: container.cpu_utilization_percent consistently above 80%.

Docker reports CPU as a per-core percentage where 100% equals one full core. A container with a 2-core CPU limit can read up to 200% raw cpu_percent at full utilization. Temps normalizes this to cpu_utilization_percent (0–100% relative to the container's CPU limit) so you can apply consistent thresholds regardless of core count. Always use cpu_utilization_percent when diagnosing or alerting on CPU pressure.

Possible causes:

  • Inefficient code or algorithms
  • Too many concurrent requests
  • Insufficient CPU allocation

Solutions:

  1. Increase CPU allocation in project settings
  2. Optimize application code
  3. Add caching to reduce computation
  4. Scale horizontally (multiple containers)

High memory usage

Symptom: Memory approaching allocation limit, container restarts.

Possible causes:

  • Memory leaks in application code
  • Insufficient memory allocation
  • Large data structures in memory

Solutions:

  1. Increase memory allocation
  2. Profile application for memory leaks
  3. Implement pagination for large datasets
  4. Use streaming for large file operations

Container restarts

Symptom: Frequent container restarts, deployment failures.

Possible causes:

  • Out of memory (OOM) errors
  • Application crashes
  • Health check failures

Solutions:

  1. Check deployment logs for error messages
  2. Review memory usage patterns
  3. Verify health check endpoint is working
  4. Check application error logs — see Error Tracking to capture and group exceptions automatically

Metrics not updating

Symptom: Monitoring dashboard showing stale data or errors.

Possible causes:

  • No active deployments
  • Network connectivity issues
  • Service unavailable

Solutions:

  1. Verify a deployment is running
  2. Check deployment status
  3. Refresh the monitoring page
  4. Contact support if the issue persists

For a unified view that merges metrics, traces, errors, and logs into a single time-ordered stream, see the Unified Observe Page.

Was this page helpful?