Features · Monitoring · Diagnostic Capture
Monitoring · Diagnostic Capture

On-demand CPU forensics,
when nothing else explains the spike.

Pick a duration + CPU threshold, hit Start. The agent runs a sampler in the background — every time CPU crosses the threshold it grabs the top 25 processes, the active Postgres queries, the MySQL processlist. Auto-stops after the window or 20 samples. AI reads every sample and names the culprit.

capture · cpu > 85% · 10 min
14:31:02 cpu 91% sampling top + pg_activity
php-fpm 62% pid 2841
postgres 24% idle in transaction
14:33:18 cpu 44% back under threshold
captured 2 windows · analysing
— Why this matters

The spike is over before you have finished logging in.

01

You cannot SSH fast enough.

By the time you are on the box, the process that pinned the CPU has exited. The sampler is already there.

02

Sampling on a threshold beats sampling always.

It waits for CPU to cross your line, takes a full snapshot, and stops itself when the window ends or the sample cap is hit.

03

Twenty snapshots need summarising.

The AI reads every sample and tells you what they have in common, which is faster than diffing them yourself.

— What's included

How a capture runs.

You set the window
One, four or twenty-four hours, with a CPU threshold.
Snapshots on crossing
Top processes and database activity, captured each time the threshold is passed.
Stops itself
At the end of the window or after the sample cap, default twenty.
AI summary
Every sample fed in, one callout out.
Cancel mid-run
From the UI, with a sweep for anything left behind.
90-day retention
Kept long enough to compare against the next one.
— How it works

Armed before the spike, not after.

1

Arm a window

You choose the metric, the threshold and how long to watch. Nothing is captured until the condition is met.

2

Snapshot on crossing

Crossing the threshold starts a series of snapshots — processes, connections, disk and memory at that moment.

3

Stop and summarise

The capture ends itself at the window or the snapshot cap, and the run is summarised rather than handed over raw.

— Works with

Connected capabilities

— FAQ

Questions, answered honestly.

Does it run all the time? +
No. You start it manually for a bounded window. The sampler only runs while CPU is above the threshold — quiet times consume nothing.
Overhead? +
When CPU is below threshold: a single top -bn2 -d1 every 60 s, < 0.1 % CPU. When above: full sample every 30 s, < 1 % CPU. Sample inserts are bulk-batched.
Why not just always run it? +
Storage. Every sample is ~10-50 KB of JSON; running 24/7 you'd accumulate gigabytes. The on-demand model captures only when there's something to see.
Can I cancel mid-run? +
Yes — the capture detail page has a Cancel button. The agent stops sampling on the next status check (≤ 30 s).
How does the AI know the cause? +
It reads every sample and looks for patterns: same process recurring, same Postgres backend, same query family. When 8 of 12 samples show php-fpm doing the same kind of work, that's the answer.
Retention? +
90 days. Captures plus their samples are kept for retroactive analysis. Cleanup runs daily.

Catch the spike, name the cause.

Diagnostic Capture from Starter. Server-side. No long-running daemon.

Get early access Back to Monitoring