# Read metrics and alerts

Open an environment's **Metrics** to compare resource use and HTTP traffic. Create resource rules in **Alerts** to record threshold crossings. **Alerts have no email, chat or webhook delivery**; inspect them in the environment.

## Before you start

- Have a service or environment-managed database with measurements to inspect.
- For MCP, use a product-scoped token with Deployment `read` for metrics/rules/events, `write` for creating or updating rules, and `admin` for deleting them.
- Choose a threshold in the metric's unit. Disk alert thresholds use percent of database capacity, even though the disk measurement is in bytes.

## 1. Read the measurements

Open **Environment → Metrics** and choose 15 minutes, one hour, six hours, 24 hours or seven days. Select targets; selecting none shows all. MCP uses [`deployment_metrics_get`](/reference/mcp-tools/deployment_metrics_get) with `targetKind` (`service` or `managed-service`), `targetId` and optional `window` (`15m`, `1h`, `6h`, `24h`, `7d`).

| Resource metric | Unit | Scope |
|---|---|---|
| CPU | Cores | Aggregated across service replicas |
| Memory | Bytes | Aggregated across service replicas |
| Network in/out | Bytes per second | Traffic entering/leaving the target |
| Disk | Bytes | Environment-managed databases only |

Static sites have no runtime container resources. They do have HTTP metrics, counted per hostname. Two static services on different paths of one hostname are reported together.

| HTTP metric | Unit | Meaning |
|---|---|---|
| Requests per second | Requests/s | Incoming request rate |
| p50, p95, p99 | Milliseconds | Latency percentiles |
| Error rate | Percent | Share of responses with a 5xx status |

HTTP metrics are measured on incoming internet traffic and include network time. Percentiles come from buckets and are approximate, especially p99. Managed databases do not have HTTP metrics.

## 2. Compare the window

Read the summary cards, **Performance** and **Resources** charts, then **Service breakdown**. CPU/memory limits also let the page show usage as a percentage. Summary p95 and error cards show the worst selected service while excluding very low-traffic services.

Deployment markers identify healthy releases, build/deploy failures and failed health checks. Compare before and after the marker rather than assuming the deployment caused a change.

HTTP data can lag by a minute or two. No recent requests means empty HTTP series; a new service has data only for its lifetime. A dash means no data for that metric, not necessarily a failure. Sampling changes with the chosen window to keep the chart readable.

## 3. Create a resource rule

Choose **Alerts → New rule**, or create a rule from the target's canvas node. MCP uses [`deployment_alert_create`](/reference/mcp-tools/deployment_alert_create).

| Choice | Values |
|---|---|
| Target | One service or managed service in the environment |
| Metric | `cpu`, `memory`, `net_in`, `net_out`; `disk` for a managed service |
| Comparator | `gt` (above) or `lt` (below) |
| Threshold | Positive number in the metric's unit; disk uses percentage |

For example, a disk rule above `80` watches for more than 80% of the database's storage capacity. Requests/s, latency and error rate cannot be used in alert rules.

Use [`deployment_alert_update`](/reference/mcp-tools/deployment_alert_update) to disable a rule without deleting it, or [`deployment_alert_delete`](/reference/mcp-tools/deployment_alert_delete) to remove it.

## Verify it works

Find the rule under **Rules**, or with [`deployment_alert_list`](/reference/mcp-tools/deployment_alert_list), and confirm its target, unit, condition, threshold and enabled state. Allow a two-minute evaluation interval and compare its state against the latest available measurement. Do not generate production load solely to trigger a rule.

When a measured crossing occurs, check **Recent firings** or [`deployment_alert_events_list`](/reference/mcp-tools/deployment_alert_events_list) for the value and threshold. The canvas marks targets with firing rules.

## How rules change state

Rules are evaluated every two minutes. A crossing changes `ok` to `firing`; returning across the threshold records a resolution. Only transitions are recorded, so an hour-long breach produces one firing entry.

No measurement leaves the rule in its current state. For a service asleep or waking under scale-to-zero, below-threshold rules are skipped. Above-threshold rules and rules for services without sleep are unaffected. Check the app to see these transitions; no external notification is sent.