Diagnostics & AI contextPrivate, in developmentDesktop · phone · agent
System Pulse
Inspect, select, compose.
A stethoscope for your computer. System Pulse, called System Sentinel until October 2026, brings a Windows PC’s events, hardware, crashes and performance into one place. Inspect it at your desk or from your phone, and let a local AI agent gather evidence through the same tool. I’ve also built a ChatGPT extension prototype for exploring performance readings and crashes in the conversation.
Runs on your Windows PC · private phone access through Tailscale · a shared interface for local agents
At your desk
Browse the dashboard
On your phone
Connect through Tailscale
Your local agent
Ask for evidence directly
On your Windows PC
System Pulse
One shared API
Read the machineKeep the evidence stack
Events
Hardware
Performance
Crashes
Three ways into the same tool. The readings and shared stack live on the PC; the phone reaches them through a private connection.
Away from the desk
Your PC’s record, on your phone.
If the computer is running at home, you can open its dashboard from your phone through Tailscale. Once that private connection is configured, choose “Sign in another device” on the computer and scan the QR code. The link signs your phone in once, within five minutes, without making you type the access token.
The phone opens the same readings and evidence stack as the desktop. Browse a crash, follow the records before it, or add a useful reading for the next conversation. The navigation keeps the current view in sight, and a copied address can bring you back to the view or investigation moment you were looking at.
ChatGPT extension · Research prototype
Ask about a slowdown. Inspect the readings.
I built the extension to bring System Pulse’s readings into a ChatGPT conversation. In supervised Desktop tests, it showed current load, performance history and leading processes. A crash timeline let me select a stop and ask about it from the side panel.
The useful connection is between the question and the record: inspect what the computer reported, then ask a more specific question about it. System Pulse supplies readings; it does not repair the machine or establish what caused a crash.
Research prototype using a local stdio connection. The recorded ChatGPT Desktop tests in October 2026 used the WSL-home Work route; the retained handoff records a reader-identity failure on the Windows-home route. These tests demonstrate the recorded experience, not current installation or public availability.
A shared investigation
Direct agent access
An agent investigating the machine can ask System Pulse for its hardware, recent stops, performance history or the records before a moment. It receives the same kind of reading the dashboard uses, with the time it was taken, how it was collected, and whether the machine answered. The collection scripts live in the tool, ready for the next question.
Agents can also use a readings-only connection over standard input and output. It does not need the tray dashboard running and cannot edit the Stack.
An agent with a connection authorized to edit the stack can add evidence alongside you. Choose the important items, put them in order, and keep each as a summary or in full. The stack stays on the PC and preserves the selected reading as it was observed. Refresh it on another device to pick up the changes.
When the context is ready, copy it, download it as Markdown, or let the agent read it directly. Edit the prompt for this handoff without changing the shared library entry. Saving it back to the library, or as a new prompt, is a separate action. Changing the question does not require collecting the evidence again.
Inspect. Open a reading, its underlying fields and the method that produced it.
Select. Add the records, snapshots or signals that matter to the shared stack.
Compose. Set the order, detail and optional prompt, then carry the same handoff into the conversation.
What it gathers
Investigating a restart
A restart leaves clues in several places. System Pulse brings together Windows’ estimate of when the computer stopped, when it started again, any recorded bug check and the last System record before the next start. Available dump files can be inspected alongside that record. Each part stays identifiable, including a source that could not be read.
Hold a moment in Event logs to inspect System entries before and after it. Crashes and Signals keep the exact event rows behind a lead beside the interpretation. You can check a cited row against the current log without replacing the original observation; the new check has its own time and may find that the row is no longer there.
Hardware-error readings draw from two Windows report logs. A bounded preview leads to a focused time window, then the exact retained report. Its filing time may differ from when the error occurred.
The GPU view adds a dated NVIDIA snapshot of load, memory, temperature, power and clocks. Windows counters show process GPU memory and activity across adapters. Missing readings stay unknown, and one snapshot describes only the moment it was taken.
Other views cover the machine’s hardware and configuration, driver changes, application crashes and reliability history. Memory and PCIe diagrams open onto the exact fields behind their summaries. A dump inspection reads bounded structural metadata and exposes the raw readout; it does not run a debugger or determine a culprit.
While System Pulse runs, it keeps a local history of aggregate processor, memory and disk activity, even with the dashboard closed. It samples every minute by default and retains up to 30 days. You can pause collection, change the interval or clear the history; a missing sample stays a visible gap.
Select a sample to inspect its exact numbers and open the System records before it. The Performance view takes a dated process snapshot when opened and again when you choose Take again. It shows processor time, private memory and I/O, with rankings that lead into the returned rows. Process names appear in that fresh reading and are kept out of the retained history.
A saved record
Freezes without a recorded event
This saved window from my own machine covers two restarts in one evening. Ordinary informational records lead into a gap; the next start writes the familiar restart events. It is a useful account of what Windows recorded, with an important limit: the last event before the gap does not, by itself, explain the freeze.
The record, read back · my own machineProviders and IDs are Windows’ own
−40 to -3.7 min91 recordsall informational: no warning, no error
no record3.6 minutes
restartKernel-General 12 · Kernel-Power 41 · EventLog 6008205 records in the first minute · the selected record
no record1.8 minutes
+6 minKernel-General 12 · Kernel-Power 41 · EventLog 6008restart, again · 216 records in the first minute
Read from my own machine’s System log with the same query the tool uses, for the fifty minutes around one evening’s two freezes. Providers, IDs and minutes are real; messages are not shown, and no date is, so the figure never ages. The log does not announce a freeze; the next start does.
Keep the evidence intact
Successful readings and empty results
Every reading distinguishes an observed empty result from a failed, unavailable, denied or timed-out collection. The dashboard explains that outcome and lets you open the complete response. Raw fields sit beside calculations and investigative leads, with the basis for each derived or inferred section available to inspect.
A quiet Signals card only describes the inputs that answered; its handoff names the input scope and gaps. Recognized identity fields and learned host or user names are masked by default, while unknown identifiers may remain in free text. Selected evidence keeps its observation time and method through the handoff.
A capture saves the evidence already on the Stack, the composed handoff and a manifest in one ZIP, without taking a new reading. Taking fresh readings is a separate choice. Open a saved reading from the capture without asking the machine to take it again.
Hardware-error bursts remain leads to investigate. They help choose where to look; they do not establish a failing component.
Design overview
One service, three ways to work with the evidence.
The Windows service gathers readings and keeps the selected evidence on the PC. The desktop dashboard presents it for a person to inspect. A phone reaches that dashboard through a configured private connection. An agent can ask for structured readings through the Model Context Protocol, the standard interface assistants use to call tools.
The shared evidence stack preserves what was observed, when it was observed and how it was obtained. People and authorized agents can select evidence for a handoff. A readings-only agent connection can inspect the machine without editing that stack.
A returned reading may be empty, or it may say the machine could not be observed. Those outcomes stay distinct. A pattern is a lead for the person or their chosen agent to investigate; it is not a diagnosis.
Gathering Windows evidence
My own machine would restart without warning on a watchdog error, some days once an hour, other days not at all, and sometimes it simply froze, as if a screenshot had been taken. I keep that computer on so I can reach it from anywhere and run long work on it, so the failures mattered.
Troubleshooting with agents meant running the long PowerShell scripts they wrote, pasting the output back, and following their directions into one Windows console after another to find a particular log. I was assembling context by hand, for a machine I wanted to understand better anyway.
System Pulse is that assembly, done once, in a place where I can browse it, and a stack I can hand to an agent when I want a second reading. It is a stethoscope for the computer: the signals were always there; now they can be heard.
Sharing a context stack
I built the interface for the person and the agent together. The dashboard turns readings into something I can browse; the agent receives their structured form. Both can choose evidence for the same stack, with its source, observation time and method kept beside it.
That decision also puts the collection work in one place. A new reading joins one catalog, and the dashboard and agent tools use the same service. I can improve how the tool gathers evidence without asking every conversation to reconstruct the collection scripts.
Questions
Does the computer need to be running?
Yes. The service runs on the Windows PC it reads. Phone access needs that PC and System Pulse running, and a way for the phone to reach it. The recommended way is Tailscale Serve, which keeps the connection on your private network.
Where is the evidence kept?
The shared stack, prompts, captures and numeric performance history are stored on the PC. Fresh readings are collected there and returned to signed-in devices or authorized agents. You choose when to copy or export evidence into another conversation.
Does it diagnose the machine?
It gathers evidence, preserves how it was obtained, and flags patterns worth investigating. You or your chosen agent interpret what those observations mean.
Source by invitation.
The source is private. Read access to the repository is available on request.