System Monitoring
{"content":"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.\n\nThink 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.**\n\n{{\u003c 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\" \u003e}}\n\n## What this page covers\n\n- The four runtime KPI cards\n- CPU and memory trend charts\n- Process details for support and diagnostics\n\n---\n\n## Runtime KPIs\n\nFour cards at the top give you an at-a-glance view of runtime health:\n\n### Process CPU\n\nCPU utilization for the Valdr process itself.\n\n| Reading | What it means |\n|---------|---------------|\n| **Main value** | Total process CPU percentage |\n| **User / System split** | CPU time spent on Valdr's work and operating-system activity |\n| **Host load avg** | Host OS load average (1 / 5 / 15 min) for context |\n\nIf 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.\n\n### Process Memory (RSS)\n\nResident memory (RSS) — how much physical RAM Valdr is currently using.\n\n| Reading | What it means |\n|---------|---------------|\n| **Main value** | Total RSS in MB |\n| **Heap / External** | Memory allocated for application work and other process resources |\n| **Heap % of RSS** | Share of total process memory used by application allocations |\n\nA steadily climbing RSS that never drops can indicate a memory leak. Check the memory trend chart below to see the shape over time.\n\n### Host Memory\n\nHost-wide memory pressure — the whole machine, not just Valdr.\n\n| Reading | What it means |\n|---------|---------------|\n| **Main value** | Percentage of host memory in use |\n| **Used / Total** | Absolute GB used of total installed |\n| **Free** | How much headroom is left on the host |\n\nHigh 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.\n\n### Event Loop (p99)\n\nEvent loop latency measures delays in Valdr's responsiveness. Sustained high values can explain why the UI feels sluggish or MCP calls take longer to respond.\n\n| Reading | What it means |\n|---------|---------------|\n| **Main value** | 99th-percentile event loop delay in milliseconds |\n| **Mean / Max** | Average and worst observed delay |\n| **Std dev** | Variability — high std dev means inconsistent latency |\n\n{{\u003c callout type=\"tip\" \u003e}}\n**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.\n{{\u003c /callout \u003e}}\n\n---\n\n## Trend charts\n\nTwo live-updating area charts show the last ~5 minutes of runtime behavior:\n\n### CPU trend\n\nStacked area chart of User % and System %. Toggle each series on/off via the legend buttons.\n\n- **User %** — CPU time spent on Valdr's work\n- **System %** — CPU time spent on operating-system services, such as network and file access\n\nLook for:\n- **Sustained high usage** — agents are actively generating heavy load\n- **Periodic spikes** — brief bursts of background or scheduled work\n- **Flat low usage with no activity** — Valdr is idle; if you expected work, check that sessions actually launched\n\n### Memory trend\n\nArea chart comparing RSS to heap usage over time.\n\n- **RSS (MB)** — total resident memory (physical RAM)\n- **Heap Used (MB)** — memory allocated for application work\n\nLook for:\n- **Steady growth without drops** — possible leak; capture diagnostics\n- **Sawtooth pattern** — memory rises and falls as unused allocations are released\n- **RSS climbing while heap stays flat** — other process memory is increasing; include this chart in a support report\n\n---\n\n## Process details\n\nThe bottom panel shows everything you'd need to include in a support ticket or bug report:\n\n| Field | What it's for |\n|-------|---------------|\n| **PID (Parent)** | Process and parent IDs — useful for `ps`, `lsof`, orphan detection |\n| **Version** | UI and MCP versions — always include when reporting issues |\n| **Runtime** | Installed runtime versions — include these when reporting an issue |\n| **Exec path** | Absolute path to the `valdr` binary |\n| **Process title** | How the process appears in `ps` output |\n| **Host** | Machine hostname |\n| **Platform** | OS + architecture (e.g., `darwin / arm64`) |\n| **PM DB Path** | Full path to the local database holding your projects, tasks, and sessions |\n| **PM DB Size** | Current database size — helps gauge storage pressure |\n| **Uptime** | How long this process has been running |\n| **Poll interval** | How often System Monitoring samples metrics (default 5s) |\n| **History window** | Trend chart retention window (default 300s / ~60 samples) |\n| **Last updated** | Timestamp of the most recent sample |\n\nThese fields are especially valuable when:\n\n- **Reporting a bug** — copy the Version, Runtime, Platform, and Uptime into your report\n- **Locating the database** — the PM DB Path tells you exactly where your local data lives (great for backups)\n- **Debugging a stuck process** — Uptime and PID pair with `ps` and `lsof` for process-level diagnostics\n\n{{\u003c callout type=\"info\" \u003e}}\n**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.\n{{\u003c /callout \u003e}}\n\n---\n\n## When to use System Monitoring\n\n| Scenario | What to check |\n|----------|---------------|\n| **UI feels sluggish** | Event Loop p99 — if it's spiking, something is blocking the loop |\n| **Agent launch is slow** | CPU trend during the launch — is Valdr CPU-saturated? |\n| **Suspected memory leak** | Memory trend over several minutes — is RSS climbing without dropping? |\n| **Host is struggling** | Host Memory card — is the whole machine tight, not just Valdr? |\n| **Filing a bug report** | Process details panel — copy version, runtime, platform |\n| **Locating your data** | PM DB Path in the process details panel |\n\n---\n\n## Next steps\n\nValdr 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.","description":"Real-time visibility into the Valdr runtime — CPU, memory, event loop health, and process details all in one place.","title":"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.
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 | CPU time spent on Valdr’s work and operating-system activity |
| 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 | Memory allocated for application work and other process resources |
| Heap % of RSS | Share of total process memory used by application allocations |
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)
Event loop latency measures delays in Valdr’s responsiveness. Sustained high values can explain why the UI feels sluggish or MCP calls take longer to respond.
| 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 |
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.
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 on Valdr’s work
- System % — CPU time spent on operating-system services, such as network and file access
Look for:
- Sustained high usage — agents are actively generating heavy load
- Periodic spikes — brief bursts of background 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) — memory allocated for application work
Look for:
- Steady growth without drops — possible leak; capture diagnostics
- Sawtooth pattern — memory rises and falls as unused allocations are released
- RSS climbing while heap stays flat — other process memory is increasing; include this chart in a support report
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 | Installed runtime versions — include these when reporting an issue |
| 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 local database holding your projects, tasks, and 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
psandlsoffor process-level diagnostics
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.
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 and come back here if anything feels off. Want deeper observability for agent work specifically? See the Agent workload dashboard for throughput and quality metrics across your sessions.