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

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 CLI

# Current metrics for every container in an environment
bunx @temps-sdk/cli containers metrics -p my-app -e production

# A single container, as JSON
bunx @temps-sdk/cli containers metrics -p my-app -e production -c <container-id> --json

# Continuously refresh (live watch mode)
bunx @temps-sdk/cli containers metrics -p my-app -e production --watch

See the CLI reference for all flags.

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

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

Setting up health checks

The health check path is set at deploy time, either in Project Settings → Deployment, or from the CLI on the deployment method that's building your image — deploy:image, deploy:static, or deploy:local-image all accept --health-check-path (e.g. bunx @temps-sdk/cli deploy:image --image ghcr.io/my-org/my-app:latest -p my-app --health-check-path /health). The base git-based deploy command does not accept this flag.

• Path: Endpoint to check (e.g., /health or /api/health). Set to empty to disable HTTP health checks.

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

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

Monitor trends

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.