Read metrics and alerts

Compare service measurements and set resource thresholds visible in the app.

Copy page

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 with targetKind (service or managed-service), targetId and optional window (15m, 1h, 6h, 24h, 7d).

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 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.

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 to disable a rule without deleting it, or deployment_alert_delete to remove it.

Verify it works

Find the rule under Rules, or with 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 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.