# 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](/docs/databases/postgres) and [Redis](/docs/databases/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](/docs/services/resources-and-scaling).

## Read a service's charts

1. 
2. 
3.

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](/docs/services/resources-and-scaling).

A [serverless](/docs/services/scale-to-zero) 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](/docs/observability/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](/docs/account/usage-and-limits). Requesting a range beyond your retention isn't an error: the window is clamped server-side to what your plan keeps.

> **Note:**
>
> Koo doesn't warehouse your metrics. Every query — chart or API — is read live from Koo's hosting layer, so what you see is the source of truth, bounded by your plan's window.

## 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](/docs/observability/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:

```text
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:

```text
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](/docs/developers/api-tokens). The full request and response shapes are in the [observability API reference](/api/observability).