> ## Documentation Index > Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt > Use this file to discover all available pages before exploring further. # Metrics > Track deployment history across the org and live resource usage per service. There are two views of how things are running: an organization-wide dashboard of deployment history, and a per-service tab of live resource usage. ## Org dashboard The **Metrics** page in the organization sidebar covers your deployment history. The numbers come from deployment records rather than sampling, so they are exact. ![Org metrics dashboard](https://mintcdn.com/slipway/XQ-cfaZA6zvMJ_Pi/images/metrics/dashboard.png?fit=max\&auto=format\&n=XQ-cfaZA6zvMJ_Pi\&q=85\&s=920149db53dedc790c8b91a862c29923) | Tile | Shows | | - | - | | **Deployments by trigger** | Counts split across push, pull request and manual. | | **Success rate** | Share of deployments that reached `healthy`. | | **Failure breakdown** | Failures grouped by the phase they happened in. | | **Build duration** | p50, p90 and p99 build times per repository. A spike usually means a heavier base image. | | **Top repos and authors** | The most active repositories and commit authors. Authors are attributed from the commit, even if they have never signed in. | | **Active deployments** | How many deployments are currently healthy. | Pick a window of 24 hours, 7 days, 30 days or 90 days. All tiles share it. Only completed deployments count, so in-flight ones do not appear in the success-rate or failure tiles until they finish. ## Project resource usage Every project's page has a **Metrics** tab showing CPU, memory and request throughput over time, as a total line plus a breakdown per service or per pod. Sampling is always on, the first points appear within a minute of a deploy, and 30 days of history are kept. * **CPU** is actual usage in millicores (1000m = 1 core), not the request or limit. * **Memory** is the container working set. * **Requests** is throughput at the public edge, split by status class, so a deploy that starts erroring is visible at a glance. Service-to-service calls inside the project do not pass the edge and are not counted. * **Network egress** is the bytes each service sent through the edge, as a total line and one per service. WebSocket and other long-lived connections are included; traffic between services inside the project is not. The window picker offers presets from the last 30 minutes through the last 30 days, or **Custom** for an exact start and end. Preset windows are live: they slide forward and the charts refresh every 30 seconds. A custom window is fixed to the dates you chose and stops updating, so re-pick a preset to go live again. The table lists each group's average and peak. **By service** is the default and keeps a stable line across redeploys; **By pod** shows individual pods. The selected window is part of the page URL, so a refresh keeps it and the link is shareable. A custom window cannot reach further back than 30 days, which is how long samples are kept. ## Service metrics Every service has its own **Metrics** tab under Monitor, showing the same window picker and the blocks that apply to it: | Block | Shows | | - | - | | **Memory Usage** | The container working set. | | **CPU Usage** | Actual usage in millicores (1000m = 1 core), not the request or limit. | | **Request Latency** | p50 and p95 response time, measured at the edge. | | **Network egress** | Bytes sent through the edge, WebSocket frames included, the same measure your bandwidth allowance uses. | | **Requests** | Throughput at the public edge. | | **Disk usage** | Filesystem bytes used, against the disk's size. | | **Active connections** | Open client connections, for managed databases. | Which blocks appear depends on what the service can actually produce: * **Web services** get everything. Latency, egress and requests are measured at the edge, so they cover external traffic only. Egress counts WebSocket traffic as well as ordinary responses. * **Internal services, workers and cron jobs** get memory and CPU. They have no public hostname, so nothing measures latency or egress for them. * **Managed databases** get memory, CPU, active connections and disk. * **Disk usage** appears for any service that mounts a disk, and always for a database. * **Static sites** have no Metrics tab, because they run no pods. Their edge traffic is measured separately: see [Static sites](/services/static#traffic). Memory, CPU, requests, egress and connections are sampled every 30 seconds and kept for 30 days. Disk is sampled about every 2 minutes, because it moves slowly. Latency comes from the edge request log, which is kept for 7 days; ask for a longer window and the latency chart starts where its history does. A latency bucket with no requests is drawn as a gap rather than as zero, because no traffic means there is no response time to report. ## How far back you can look Your plan sets how far back metrics and logs can be read. Windows longer than that carry a lock in the picker, and clicking one explains what a higher plan reaches. Storage does not change with your plan. Samples and log lines are kept for the full 30 days regardless, and the plan bounds the query only. Upgrading shows the older history straight away with no backfill, and downgrading hides history rather than deleting it. One number covers both metrics and logs. Your current limit is on the [Billing](/organization/billing) page, and every plan's is on [Plans](/plans). > [!NOTE] > > Projects on a [cluster you bring](/clusters/byok) are not sampled, so their Metrics tab is empty. Disk usage also needs a cluster agent recent enough to report volume statistics; an older agent leaves that block empty while the rest keep working. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.