Metrics

Every service reports CPU and memory — databases included. Web services that take traffic add request rate and request latency. Koo reads them on demand from its hosting layer: as charts in the console, and as raw time series through the API.

What's measured

CPU and memory are reported for every service, including Postgres and Redis databases. Request rate and latency cover web services that receive traffic.

A service's CPU and memory settings cap what it has available. Sustained high CPU or memory is the usual signal to give the service more — see resources & scaling.

Read a service's charts

1. Open the environment canvas and click the service's node — its drawer opens.
2. Open the Metrics tab. It shows a chart per metric.
3. Use the range control to widen or narrow the time window. Ranges are capped at your plan's metrics retention.

A chart can carry more than one series — each series is labeled, so you can tell them apart.

Environment-wide metrics

The environment rail's Metrics page charts the whole environment. It shows a headline tile and a chart for each of the four metrics, with a per-service breakdown under the CPU, memory, and request charts so you can see which service is behind a spike.

Latency is shown as the environment-wide p95 only — per-service latency percentiles don't add up to a meaningful total, so it never gets breakdown rows. An environment with no web services takes no HTTP traffic, so the request and latency charts don't appear there.

Replicas

A web service runs a fixed replica count per location — a number you set on the service. There is no metric-based autoscaler: the charts on this page are for you to read, and changing the count is a spec edit, covered in resources & scaling.

A serverless service scales between zero and its replica count with traffic — the count is the ceiling, not a target. Databases always run exactly one replica.

How many replicas are ready right now versus desired is part of status, not metrics.

Retention

How far back you can query depends on your plan — each plan's metrics retention window is listed in usage & limits. Requesting a range beyond your retention isn't an error: the window is clamped server-side to what your plan keeps.

Metrics vs status

Metrics show usage over time; status shows current truth. After a deploy, confirm the service is running from its status — not from a dip or spike in the charts. Use metrics to answer "how has this behaved over time?" and status to answer "is this healthy right now?"

For the request-by-request view, see logs.

Fetch metrics from the API

Each request returns one metric as a JSON time series — labeled series of timestamped points, with the unit, resolved range, and step size. Per service:

curl "https://api.koo.io/accounts/{accountId}/projects/{projectId}/environments/{environmentId}/services/{name}/metrics?metric=cpu&range=1h" \  -H "Authorization: Bearer kc_…"

And across a whole environment:

curl "https://api.koo.io/accounts/{accountId}/projects/{projectId}/environments/{environmentId}/metrics?metric=cpu&range=1h" \  -H "Authorization: Bearer kc_…"

metric is one of cpu, mem, req, or latency; range is a relative window like 1h, clamped to your plan's retention. In the environment-wide response, the first series is the environment-wide aggregate and a services field breaks it down per service for cpu, mem, and req.

These calls authenticate with an API token. The full request and response shapes are in the observability API reference.