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	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

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 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

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.

Settings