Metrics
The Overview tab of a deployment charts what it is using and, for a public web app, what traffic it is serving. The charts come from Ownkube’s own telemetry; you do not add an agent or a library.
Resource metrics
Section titled “Resource metrics”Every web app, worker, job, database and cache shows:
| Metric | What it measures |
|---|---|
| CPU | vCPU in use, against the limit you set. |
| Memory | The working set the container holds, against its memory limit. |
| Replicas | Running against desired, for example 3 / 3. |
| Restarts | Container restarts in the window. A climbing count means the app is crashing. |
These are the numbers autoscaling scales on and alerts fire on. A metered app bills on them too: see Understanding your bill.
Request metrics
Section titled “Request metrics”A web app with a public hostname also gets the Observability panel, sourced from the region edge:
| Metric | What it measures |
|---|---|
| Requests by status | Request rate per minute, split into 2xx, 3xx, 4xx and 5xx. |
| p95 latency | The response time 95% of requests beat, as seen by the edge. |
| Network in | Bytes received from clients. |
| Network out | Bytes sent to clients. Billed per GB; see Regions. |
A worker or an app with its public hostname off has no edge traffic, so the panel does not show. Traffic over the private network is not counted here.
The time picker
Section titled “The time picker”One picker on the Overview tab sets the window for every chart: the last 15 minutes, hour, 6 hours or 24 hours, or a custom from and to with a step. The same window follows you to the Logs tab, so an incident you spot on a chart is one click from the lines that explain it.
From the terminal
Section titled “From the terminal”okctl deploy telemetry <id> # CPU, memory and replicasokctl deploy observability <id> # requests, latency and errorsBoth print a table; add -o json for scripting. A coding agent connected through the MCP server can read the same numbers.
Reading the charts
Section titled “Reading the charts”- CPU flat at the limit with latency rising: the app needs a bigger limit or more replicas. Turn on autoscaling on CPU.
- Memory climbing between restarts: a leak. The restart count on the same chart confirms it. Set a memory alert while you fix it.
- 5xx rising with CPU flat: the problem is downstream, usually the database. Check its CPU and the Logs for connection errors.
- 4xx rising: clients, not the app. Look at the paths in the logs.
Retention
Section titled “Retention”Metrics are kept for 7 days on Pay as you go, 30 days on Personal and 90 days on Team.