> ## Documentation Index
> Fetch the complete documentation index at: https://paper.brimble.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Project metrics

> Every Brimble project has an Observability tab that shows CPU, memory, network, and response-time metrics in real time.

Every Brimble project has an **Observability** tab that shows CPU, memory, network, and response-time metrics in real time. Use it to size your project, debug latency spikes, and watch traffic patterns.

This is separate from [web analytics](../analytics/web-analytics), which counts visitors and pageviews on the front end. Observability metrics are server-side, what your container is doing.

## Open the Observability tab

1. In the dashboard, open the project.
2. Click **Observability**.

The tab loads with metrics for the last hour by default.

<Frame caption="The Observability tab on a project.">
  <img src="https://mintcdn.com/brimble-86/VDnKCHWcGHKvY1rj/images/observability/cpu-memory-metrics.jpg?fit=max&auto=format&n=VDnKCHWcGHKvY1rj&q=85&s=f2589aad0e5486463bf9e17bfddb0488" alt="Observability tab on a web-service project showing two semi-gauges (CPU, Memory) at the top and a time-series chart below with tabs for Memory Usage" width="5088" height="3366" data-path="images/observability/cpu-memory-metrics.jpg" />
</Frame>

## Top: live gauges

Two semi-circular gauges show the **current** snapshot:

* **CPU usage**, percentage of allocated CPU in use, with the allocation in vCPU shown alongside (for example `7.2% - 2.0 vCPU`).
* **Memory usage**, percentage of allocated memory in use, with the allocation in GB (e.g. `1.8% / 1.5 GB`).

These are point-in-time readings. The chart below shows how they've moved over your selected window.

## Bottom: time-series chart

Pick a metric from the tabs above the chart:

| Metric             | Unit | Description                                                                                                                            |
| ------------------ | ---- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Memory Usage**   | %    | Memory consumption as a percentage of the project's allocated memory.                                                                  |
| **CPU Usage**      | %    | CPU consumption as a percentage of the project's allocated CPU.                                                                        |
| **Network Egress** | KB/s | Outbound network throughput from your container.                                                                                       |
| **Response Times** | ms   | Latency percentiles for HTTP responses. Toggle between **P90**, **P95**, **P99**, and **Average**. Not available on database projects. |

The chart's X-axis is time; the Y-axis is the metric. Hover any point to see the exact value at that timestamp.

<Frame caption="Network Egress chart over the last hour.">
  <img src="https://mintcdn.com/brimble-86/VDnKCHWcGHKvY1rj/images/observability/network-egress.jpg?fit=max&auto=format&n=VDnKCHWcGHKvY1rj&q=85&s=e34ea7a042a5853f31d551eafc683c6e" alt="Time-series chart showing outbound network throughput in KB/s" width="5088" height="3366" data-path="images/observability/network-egress.jpg" />
</Frame>

### Response Time percentiles

For web services and MCP servers, the Response Times tab is the most useful one for catching tail latency:

* **P90**, 90% of responses were faster than this. Useful for "typical worst case."
* **P95**, 95% of responses were faster. Use for SLOs.
* **P99**, 99% of responses were faster. Most actionable signal for tail latency, if P99 is bad, a meaningful slice of users are seeing it.
* **Average**, sum of all response times divided by request count. Easy to read but hides outliers; prefer percentiles for real analysis.

Toggle between them with the **P90 / P95 / P99 / Average** segmented control on the right side of the chart header.

## Time range

The dropdown in the top right of the tab picks the time window:

* Last 1 Hour (default)
* Last 6 Hours
* Last 24 Hours
* Last 7 Days
* Last 30 Days

Switching the range refreshes the chart and the gauges. Longer ranges aggregate more, minute-level resolution at 1 hour, hourly aggregates at 7+ days.

## Reading the chart

A few patterns worth recognizing:

* **Memory climbing steadily over hours, then dropping when the deployment restarts.** That saw-tooth shape is a leak. The chart confirms it; finding what's holding allocations is on you.
* **P99 response time much higher than P90.** A small slice of requests are slow. Usually a slow downstream (a database query, a third-party API) on specific paths. Cross-reference with request logs.

## Database projects

Database projects show **Memory Usage**, **CPU Usage**, and **Network Egress**, the same gauges and the same chart. They don't have **Response Times** because Brimble doesn't time individual queries from the platform side; for query-level performance, use the database engine's native tools (e.g. `pg_stat_statements` for PostgreSQL).

## Workspace bandwidth

Per-project network egress is on the Observability tab. The **workspace's total bandwidth** is on the home page in the **Bandwidth** tile, with a small chart showing the usage trend across the current cycle.

Bandwidth is what's billed against your plan's allowance, see [Plans and pricing](../billing/plans) for the limits and overage rate.

## Refresh and freshness

Metrics auto-refresh when you change the time range. They don't auto-tick within a fixed window, to pull the latest second-by-second data, switch ranges (e.g. flip from 1 Hour to 6 Hours and back).

There's no manual refresh button on the Observability tab. The data behind it has a few-seconds lag from the source.

## Where to find error and request data

Errors and request volume don't live on the Observability tab. They're under **Logs**:

* **Error rates over time** appear in the application-logs trend chart, with stacked counts for error, warn, and info levels across your selected window.
* **HTTP errors** appear in the request-logs view, with a status filter (`2xx`, `4xx`, `5xx`) and a detail drawer per request.

See [Logs](/observability/logs) for the full breakdown.

For per-endpoint latency, error attribution, traces, or anything close to full APM, ship telemetry to a third-party service (Sentry, Datadog, Grafana Cloud, and similar). Brimble's metrics tab covers platform health.

## Troubleshooting

**Gauges show 0% with traffic.** The metrics pipeline lags by a few seconds for fresh deployments, wait a minute and refresh. If still zero after a few minutes, runtime metrics may be unavailable temporarily; check [status.brimble.io](https://status.brimble.io).

**Response Times tab is missing.** You're on a database, worker, or static-site project. Response times only apply to projects that handle HTTP requests (web service, MCP server).

**Numbers look wrong vs. my own monitoring.** Brimble's CPU and memory percentages are relative to the **allocation** you picked under **Settings → Resources**, not the host's total capacity. If your container's `top` shows 30% but Brimble shows 90%, your container is using 90% of what Brimble gave it.

## Next steps

* [Configure scaling](../scaling/overview), when CPU or memory hit ceiling.
* [Web analytics](../analytics/web-analytics), visitor-facing analytics, separate from these metrics.
* [Plans and pricing](../billing/plans), bandwidth allowance and overage.