Monitoring

Temps collects CPU, memory, network, and request metrics for every deployed container — no external monitoring service needed. On top of those metrics you can set threshold alert rules, and run HTTP uptime monitors that open an incident and notify you when a check fails, so you don't need a separate Pingdom-style service.

For the product overview, see self-hosted observability; for tuning once you have numbers, see Performance.

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. Open the environment you want to inspect (for example production)
3. Switch to its Metrics view for live CPU, memory and network I/O per container

Request volume and latency (p95/p99) are on the project overview. The project's Metrics page charts every stored metric series, including the container.* gauges (container.cpu_utilization_percent, container.memory_used_bytes, …), and is where alert rules live.

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.

You can also set the path as health.path in .temps.yaml. Before switching traffic to a new deployment, Temps probes that path (or /) every 5 seconds and needs 2 consecutive successes. If the app isn't healthy within 5 minutes, or keeps answering with error responses for 60 seconds in a row, the deploy fails and the old deployment keeps serving.

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

Uptime monitors

An uptime monitor sends an HTTP request to one of your environments on a fixed interval and records whether it is operational, degraded or down. A 2xx or 3xx response counts as operational. A 5xx response, a timeout or a refused connection marks the check as an outage, and Temps opens an incident and notifies you on the first failed check. When the next check succeeds, the incident is resolved.

# Create a monitor (interval in seconds: 60, 300, 600, 900 or 1800)
bunx @temps-sdk/cli monitors create --project-id <project-id> \
  --name "Production health" --type http --interval 60 --check-path /api/healthz -y

# List monitors, then check one monitor's current status and history
bunx @temps-sdk/cli monitors list --project-id <project-id>
bunx @temps-sdk/cli monitors status --id <monitor-id>
bunx @temps-sdk/cli monitors history --id <monitor-id> --days 7

How checks behave:

• The check URL is built from the environment's address plus the check path (default /). Point it at a cheap health endpoint, not your homepage.
• Each request times out after 10 seconds. Timeouts are retried up to 3 times before the check is recorded as failed; a refused connection is recorded straight away.
• Outage notifications go to the providers and routes you configure under Notifications (email, Slack or webhook). The backups and monitoring tutorial walks through setting one up and simulating a failure.

Incidents and status overview

Incidents record outages for a project. Temps opens one automatically when a monitor fails and resolves it when the monitor recovers. You can also open one by hand, for example for planned maintenance or a problem a monitor can't see, and post status updates to it:

# Open an incident and post updates to it
bunx @temps-sdk/cli incidents create --project-id <project-id> \
  --title "Checkout errors" --severity major --description "Investigating 5xx on /checkout" -y
bunx @temps-sdk/cli incidents update-status --id <incident-id> --status resolved \
  -m "Fixed by redeploying the previous release"

# List open and past incidents
bunx @temps-sdk/cli incidents list --project-id <project-id>

The project's status overview combines every monitor's current state, uptime history and open incidents. It is part of the authenticated dashboard and API (GET /api/projects/{project_id}/status); Temps does not publish a public status page.

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 → Environment settings and pick the environment (limits are set per environment)
2. Set CPU (in cores) and Memory (MB; 0 means no memory cap)
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

Metric alert rules live on the project's Metrics page, under the Alerts tab:

1. Open your project, go to Metrics and select Alerts.
2. Create a rule: give it a name, pick the metric and aggregation, then set the comparator, threshold and For duration (seconds) the condition must hold before the alert fires. Set a severity.
3. Make sure a notification provider (email, Slack or webhook) and a route exist under Notifications, so firing alerts reach someone. See Set up a notification channel.

Good starting 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 — use an uptime monitor for these

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

To see the requests, traces, errors and revenue events around an incident in one time-ordered timeline, use Observe. Container metrics and logs are not part of that timeline; they stay on this page and in Logs.