Performance Monitor — every block, in detail

What it is

The Performance Monitor answers "how is this performing right now?" from one snapshot. That snapshot is read as a set of blocks — box, birth rate, the app's main thread, memory, fleet, disks, and the rest — and each block is deliberately narrow: it reports what it measured, names the window it measured it over, and says when it could not read something rather than showing a calm zero.

This page is the block-by-block reference. Read it when a number on the scorecard surprises you, when you need to know whether a block covers something, or when you are deciding whether a reading is a fact about the machine or a gap in the measurement.

Where to find it

The blocks are what the Performance Monitor shows: Developer Tools → Performance Monitor in the app, the same scorecard at GET /perf/status, and the same again in a terminal with npm run perf:status. All three read ONE snapshot, so a panel reading and a scripted reading can never disagree about a block.

How it behaves

Each block answers one question and carries its own window. A block that cannot read its source says so with the reason; a block that has no history yet says how much of the window it saw. Neither ever renders as a healthy zero.

Block	What it answers
Box	CPU busy · kernel share · pressure faults per second · event-loop lag · RAM free and RAM available, labelled separately. The kernel share reads n/a — never 0% — when the sampler has no real two-sample delta yet; 0% means a measured calm. RAM available is the reading taken at the last stall, not a live one, so it says when (at the last stall, 14:05, with the date once it is not from today, or at the last stall, time unknown) or why there is no number: no stall in this window, no reading on the last stall, or stall log not read — blind, which is not a calm window
Birth rate	How fast the whole box is manufacturing processes, per live session — demand-zero faults per second divided by the number of live agent sessions. Carries the threshold it was compared against, how many consecutive readings have been over it, and how many child launches the app's own spawn seam has made. Read it beside Box, never instead of it: they genuinely diverge — a box can be at 100% CPU without a birth storm, and a birth storm is what a box full of 200 ms processes looks like. n/a means the reading could not be taken, which is not a calm box.
App main thread	What share of the window the app's main thread was stalled, how many stalls, the longest one, memory in use, blocking file-system holds, garbage-collection pauses. Plus what the app was actually doing while frozen, from two separate instruments that are never merged — see “Two instruments name a freeze” on the Performance Monitor page
Memory pool	The external-memory pool size, how fast it is refilling, and confirmed refill episodes
Fleet	Sessions by status, and how fast processes are being started, by program name
Disks	Per volume: free space, runway hours at the measured rate of change, and live worktree directories. Box-wide loose directories are reported separately, never mixed in. The rate is a fit across hours of samples, and it prints the span it used — see “Runway is a trend, not a stopwatch” on the Performance Monitor page
Drives (per drive)	One line per drive letter over the same window: busy p50 and p90 (100 − % Idle Time), mean queue depth, read/write MB/s, and read/write latency — the kernel's own service time — plus the physical disk the letter sits on, so two letters on one spindle are visible as such. Written every minute by the per-volume sampler into drive_disk_minutes (30-day retention, the same window as the box disk totals). This is the block that answers which drive and for how long: a 98 GB copy holding one volume at saturation for a fifth of the window reads a near-100 p90 while the box-wide byte total says only "the box wrote a lot". A percentile resolves to ten percentage points, so a fully saturated drive reads in the 90s rather than a literal 100; latency prints n/a — never 0ms — when no operation went that way, and a window with no recorded sample says so instead of rendering a calm zero
Other programs	How long the programs that are not Omniscio took to answer, over the window: the worst minute's p95, the overall max, how many windows hung, and which program was slowest — the answer to "did running Omniscio freeze everything else?". A five-second probe off the main thread asks the foreground window and up to ten other top-level windows SendMessageTimeoutW and IsHungAppWindow, and records one row per minute in other_programs_minutes (same 30-day retention as the box disk totals). The window figure is the worst minute, not an average, because one frozen minute in thirty would otherwise average away; an uncomputable percentile prints n/a, never 0ms. A window that does not answer counts at the full one-second budget — Windows hands a hung window back immediately, so timing it naively would rank the most frozen program as the quickest — and a window that closed between being listed and being asked is dropped rather than counted as hung. A probe that cannot run — not Windows, or the native bindings missing — prints not measured with its reason instead of an untroubled zero, and a probe that has since gone dark keeps the reading it took and flags the stop
Cloud verdicts	Attempted · green · red · no verdict — the last being a run that answered nothing, which is a different failure from a red
Auto-lander	Lands in the window and per hour, branches waiting, git wedge events and refused reads
Load gates	The harm verdict share, how often the older busy gate disagreed with it, and the pack-storm share
Governor	Every governor policy on one screen, each as THREE separate facts — what it OBSERVED, what it REQUESTED on the strength of that, and what was actually APPLIED — plus the mode it is really in, the gap between the last two, and the card that raises if it fails. Covers fleet pacing, Job containment, maintenance yield and cooperative drain. A policy whose records cannot be read says so with the reason; it never shows a green it did not measure. Each policy also carries a spread line — how many sessions were actually being held back, and how hard the worst-off one was hit — which today reports that it cannot be measured, and why
Hook host	The resident host that runs the agent hooks Omniscio injects into every session (so a tool call starts one tiny native program instead of a Node runtime): up/down/held and why, its process id and uptime, warm and in-flight workers, hooks served, held and fallen back (by reason), p50/p95, restarts, and whether THIS computer's sessions are contained by the native client at all — other systems read "not contained" and keep the per-call behaviour
Agent action time	Where your agents' time actually went, grouped by what they were doing and ranked by total wait — with every row's quiet-box and busy-box typical wait side by side, which is the pair that says whether an action is expensive or merely queued. Plus the model half, so a slow model is separable from a slow tool. See "Where the agents' own time went" on the Performance Monitor page
Call span	One agent command split into its parts and timed separately — before the hook · the hook · getting the shell started · the command itself · the CLI's own tail after the command returns — grouped by command class, so a wait has an owner instead of a total. Each class carries its call count and its typical and slow-tail time for each part, and the row names what it is blind to rather than printing a calm zero: a part with no stamp yet reads as blind with its reason, and the CLI tail is measured but never counted as Omniscio's own time
Phone	The phone's own speeds, from samples the active phone has persisted: phone tap splits a warm tap (transcript already cached) from a cold one (it had to fetch) — tap to the newest message row painting — phone load splits the reopen of the last-open session from the first inbox paint off the phone's saved copy, and phone resume is the wait after the phone comes back from the background (the visibility flip to the first fresh data frame). A phone that has not reported yet prints not measured with the reason, never a fast zero. The five timings land in perf_samples under mobile_warm_tap_ms / mobile_cold_tap_ms / mobile_warm_reopen_ms / mobile_cold_load_ms / mobile_resume_ms; that table's metric value set is closed by a trigger, so a new timing is not writable until a migration widens it
Work rate	What the fleet actually finished at each live-session count — completed turns, tool calls and branches landed per session-hour, beside lands per wall-clock hour — with the two peaks named as readings, the land record's own coverage stated, and a thin bucket printing counts rather than a rate. See "What the fleet finishes, by session count" on the Performance Monitor page
Session limit	The owner-set cap on live sessions: the limit (or OFF), the live count, the places held for starts not yet counted, and the waiting line. An instant, not a window. See Local session limit

Related

• Performance Monitor — the scorecard itself, and how to read it.
• Performance control — the switches and governors behind the numbers.