# System Monitoring
The System Monitoring page gives you a live view of the Valdr runtime itself. CPU utilization, memory pressure, event loop latency, host load — everything you need to confirm Valdr is healthy, diagnose slowdowns, or grab diagnostics when something feels off.

Think of it as the health gauge for the platform that's running your agent work. **If an agent session feels slow or a workflow stalls, start here.**

{{< thumbcard src="/images/ui/sys/sys-monitor.png" alt="System Monitoring page with KPI cards, CPU and memory trend charts, and process details" caption="Process CPU, memory, and event loop — live, at a glance, with full trend history" >}}

## What this page covers

- The four runtime KPI cards
- CPU and memory trend charts
- Process details for support and diagnostics

---

## Runtime KPIs

Four cards at the top give you an at-a-glance view of runtime health:

### Process CPU

CPU utilization for the Valdr process itself.

| Reading | What it means |
|---------|---------------|
| **Main value** | Total process CPU percentage |
| **User / System split** | Time spent executing Valdr code vs. time in syscalls |
| **Host load avg** | Host OS load average (1 / 5 / 15 min) for context |

If this stays low while your host load average is high, something else on the machine is competing for CPU. If Valdr's own CPU is high, check the CPU trend chart to see whether it's sustained or spiky.

### Process Memory (RSS)

Resident memory (RSS) — how much physical RAM Valdr is currently using.

| Reading | What it means |
|---------|---------------|
| **Main value** | Total RSS in MB |
| **Heap / External** | V8 heap allocation and external native memory |
| **Heap % of RSS** | How much of Valdr's memory is JavaScript heap vs. native structures |

A steadily climbing RSS that never drops can indicate a memory leak. Check the memory trend chart below to see the shape over time.

### Host Memory

Host-wide memory pressure — the whole machine, not just Valdr.

| Reading | What it means |
|---------|---------------|
| **Main value** | Percentage of host memory in use |
| **Used / Total** | Absolute GB used of total installed |
| **Free** | How much headroom is left on the host |

High host memory doesn't necessarily mean Valdr is the culprit — it tells you the overall environment Valdr is running in. When the host is tight, agent sessions might compete for memory or face OS-level throttling.

### Event Loop (p99)

The single most important metric for "does Valdr feel fast?" Event loop latency measures how long it takes the Node.js event loop to process a tick — anything blocking the loop (heavy JSON parsing, synchronous work, GC pauses) shows up here.

| Reading | What it means |
|---------|---------------|
| **Main value** | 99th-percentile event loop delay in milliseconds |
| **Mean / Max** | Average and worst observed delay |
| **Std dev** | Variability — high std dev means inconsistent latency |

{{< callout type="tip" >}}
**A healthy Valdr runtime keeps event loop p99 under 10ms.** If this spikes into tens or hundreds of milliseconds, the UI will feel sluggish and MCP calls will queue up. Watch for sustained high values during agent launches — that's where heavy work concentrates.
{{< /callout >}}

---

## Trend charts

Two live-updating area charts show the last ~5 minutes of runtime behavior:

### CPU trend

Stacked area chart of User % and System %. Toggle each series on/off via the legend buttons.

- **User %** — CPU time spent in Valdr's own JavaScript code
- **System %** — CPU time spent in kernel/syscalls (I/O, networking, file access)

Look for:
- **Sustained high usage** — agents are actively generating heavy load
- **Periodic spikes** — GC cycles or scheduled work
- **Flat low usage with no activity** — Valdr is idle; if you expected work, check that sessions actually launched

### Memory trend

Area chart comparing RSS to heap usage over time.

- **RSS (MB)** — total resident memory (physical RAM)
- **Heap Used (MB)** — V8 JavaScript heap consumption

Look for:
- **Steady growth without drops** — possible leak; capture diagnostics
- **Sawtooth pattern** — normal GC behavior as the heap fills and empties
- **RSS climbing while heap stays flat** — external/native memory growth (e.g., large file buffers, native modules)

---

## Process details

The bottom panel shows everything you'd need to include in a support ticket or bug report:

| Field | What it's for |
|-------|---------------|
| **PID (Parent)** | Process and parent IDs — useful for `ps`, `lsof`, orphan detection |
| **Version** | UI and MCP versions — always include when reporting issues |
| **Runtime** | Bun and Node versions powering the process |
| **Exec path** | Absolute path to the `valdr` binary |
| **Process title** | How the process appears in `ps` output |
| **Host** | Machine hostname |
| **Platform** | OS + architecture (e.g., `darwin / arm64`) |
| **PM DB Path** | Full path to the SQLite database holding all your projects, tasks, sessions |
| **PM DB Size** | Current database size — helps gauge storage pressure |
| **Uptime** | How long this process has been running |
| **Poll interval** | How often System Monitoring samples metrics (default 5s) |
| **History window** | Trend chart retention window (default 300s / ~60 samples) |
| **Last updated** | Timestamp of the most recent sample |

These fields are especially valuable when:

- **Reporting a bug** — copy the Version, Runtime, Platform, and Uptime into your report
- **Locating the database** — the PM DB Path tells you exactly where your local data lives (great for backups)
- **Debugging a stuck process** — Uptime and PID pair with `ps` and `lsof` for process-level diagnostics

{{< callout type="info" >}}
**Local-first:** Everything on this page — CPU, memory, database path, uptime — describes the process running on *your* machine. No telemetry is sent anywhere. This data is yours to inspect, and it's gone the moment you close Valdr.
{{< /callout >}}

---

## When to use System Monitoring

| Scenario | What to check |
|----------|---------------|
| **UI feels sluggish** | Event Loop p99 — if it's spiking, something is blocking the loop |
| **Agent launch is slow** | CPU trend during the launch — is Valdr CPU-saturated? |
| **Suspected memory leak** | Memory trend over several minutes — is RSS climbing without dropping? |
| **Host is struggling** | Host Memory card — is the whole machine tight, not just Valdr? |
| **Filing a bug report** | Process details panel — copy version, runtime, platform |
| **Locating your data** | PM DB Path in the process details panel |

---

## Next steps

Valdr is healthy? [Launch your first agent](/valdr/docs/ui/tasks/agent-launch/) and come back here if anything feels off. Want deeper observability for agent work specifically? See the [Agent workload dashboard](/valdr/docs/ui/dashboard/agent-workload-pulse/) for throughput and quality metrics across your sessions.