You close your laptop.
The screen goes dark.
You assume everything stopped.
But what if it didn't?
Maybe Docker is still transferring data.
Maybe Chrome is still downloading something.
Maybe an application is consuming CPU in the background.
Maybe your computer woke up at 3 AM, performed some background work, and went back to sleep.
Most operating systems already expose pieces of this information.
The interesting part is putting those pieces together.
That's what I wanted to explore:
Can we build an observability layer for a desktop computer using Electron?
Not another CPU/RAM widget.
Something that answers:
What is my computer actually doing?
The Idea
Imagine opening your desktop monitoring application and seeing:
TODAY
────────────────────────────────────

Computer active        7h 42m
Idle                   1h 13m
Sleep                  8h 05m

Network
↓ Download             6.8 GB
↑ Upload               1.2 GB

Top applications
────────────────────────────────────

VS Code                3h 42m
Chrome                 2h 18m
Docker                 1h 31m
Slack                  52m

Network-heavy apps
────────────────────────────────────

Docker                 2.4 GB
Chrome                 1.8 GB
VS Code                920 MB
Enter fullscreen mode
Exit fullscreen mode
Now imagine clicking
"What happened while I was away?"
18:42  User became idle
18:51  Screen locked
18:53  Docker network activity
19:07  Background sync completed
19:14  System entered sleep
Enter fullscreen mode
Exit fullscreen mode
That's much more interesting than a CPU percentage.
The npm Package That Makes This Easier
Instead of writing native system integrations for everything ourselves, we can start with:
npm
install
systeminformation
Enter fullscreen mode
Exit fullscreen mode
systeminformation
provides APIs for system information, CPU, memory, battery, filesystem, network, processes, Docker and more. It also supports Linux, macOS and Windows, although individual APIs have platform-specific support.
For example:
const
si
=
require
(
"
systeminformation
"
);
async
function
getSystemStats
()
{
const
[
cpu
,
memory
,
battery
,
network
]
=
await
Promise
.
all
([
si
.
currentLoad
(),
si
.
mem
(),
si
.
battery
(),
si
.
networkStats
()
]);
return
{
cpu
:
cpu
.
currentLoad
,
memory
:
memory
.
active
,
battery
:
battery
.
percent
,
network
};
}
console
.
log
(
await
getSystemStats
());
Enter fullscreen mode
Exit fullscreen mode
Now our Electron main process can periodically collect system information.
Monitoring Network Activity
One of the most useful APIs is:
si
.
networkStats
()
Enter fullscreen mode
Exit fullscreen mode
It provides network statistics including received/transmitted bytes and calculated per-second rates. The package calculates rates based on differences between successive calls, so the first call doesn't provide a meaningful rate yet.
A simple monitor:
const
si
=
require
(
"
systeminformation
"
);
setInterval
(
async
()
=>
{
const
stats
=
await
si
.
networkStats
();
for
(
const
network
of
stats
)
{
console
.
log
({
interface
:
network
.
iface
,
download
:
network
.
rx_sec
,
upload
:
network
.
tx_sec
});
}
},
1000
);
Enter fullscreen mode
Exit fullscreen mode
Now we have something like:
Wi-Fi
Download: 2.4 MB/s
Upload:   180 KB/s
Enter fullscreen mode
Exit fullscreen mode
But this is only the beginning.
Network Connections
We can also inspect active network connections:
const
connections
=
await
si
.
networkConnections
();
console
.
log
(
connections
);
Enter fullscreen mode
Exit fullscreen mode
This gives us information about active TCP/UDP connections.
That means we can potentially build:
Active Connections
────────────────────────────

TCP    443    api.example.com
TCP    443    github.com
TCP    443    google.com
UDP    53     DNS
Enter fullscreen mode
Exit fullscreen mode
Now the dashboard starts becoming useful for troubleshooting.
Which Application Is Active?
Network traffic alone doesn't tell us
who is responsible
.
We also want to know which application the user is interacting with.
One option is a native active-window module such as:
npm
install
@jannchie/active-window
Enter fullscreen mode
Exit fullscreen mode
The package exposes information about the currently selected window and user idle time on supported Windows, macOS and Linux/Xorg environments. Platform coverage isn't identical everywhere, so this should be treated as an OS-dependent component.
Conceptually:
const
activeWindow
=
require
(
"
@jannchie/active-window
"
);
async
function
getActiveApp
()
{
const
window
=
await
activeWindow
().
getActiveWindow
();
return
{
process
:
window
.
windowClass
,
title
:
window
.
windowName
};
}
Enter fullscreen mode
Exit fullscreen mode
Then we can record:
10:32:14  VS Code
10:32:15  VS Code
10:32:16  VS Code
...
10:45:02  Chrome
10:45:03  Chrome
Enter fullscreen mode
Exit fullscreen mode
Instead of storing every second individually, we can aggregate this into sessions.
VS Code
10:32 → 10:45
Duration: 13 minutes
Enter fullscreen mode
Exit fullscreen mode
Sleep and Wake
This is where Electron itself becomes useful.
Electron provides the
powerMonitor
module for monitoring system power-state changes, including suspend/resume, AC/battery changes, idle state and lock/unlock events on supported platforms.
In the Electron main process:
const
{
powerMonitor
}
=
require
(
"
electron
"
);
powerMonitor
.
on
(
"
suspend
"
,
()
=>
{
console
.
log
(
"
System is going to sleep
"
);
});
powerMonitor
.
on
(
"
resume
"
,
()
=>
{
console
.
log
(
"
System woke up
"
);
});
Enter fullscreen mode
Exit fullscreen mode
We can turn those events into database records:
function
recordEvent
(
type
)
{
db
.
insert
({
type
,
timestamp
:
new
Date
()
});
}
powerMonitor
.
on
(
"
suspend
"
,
()
=>
{
recordEvent
(
"
system_sleep
"
);
});
powerMonitor
.
on
(
"
resume
"
,
()
=>
{
recordEvent
(
"
system_wake
"
);
});
Enter fullscreen mode
Exit fullscreen mode
Now our timeline knows when the machine slept.
Idle Detection
Electron also provides:
powerMonitor
.
getSystemIdleTime
()
Enter fullscreen mode
Exit fullscreen mode
and:
powerMonitor
.
getSystemIdleState
(
60
)
Enter fullscreen mode
Exit fullscreen mode
The latter can return states such as
active
,
idle
, or
locked
on supported systems.
For example:
const
state
=
powerMonitor
.
getSystemIdleState
(
60
);
const
idleSeconds
=
powerMonitor
.
getSystemIdleTime
();
console
.
log
({
state
,
idleSeconds
});
Enter fullscreen mode
Exit fullscreen mode
We can therefore distinguish:
Active
   ↓
Idle
   ↓
Locked
   ↓
Sleep
Enter fullscreen mode
Exit fullscreen mode
That's much more meaningful than simply measuring application runtime.
Putting Everything Together
Now imagine collecting events from four sources:
Electron App
                      │
       ┌──────────────┼──────────────┐
       │              │              │
  powerMonitor   systeminformation   active-window
       │              │              │
       │         CPU / RAM / Net     Active App
       │              │              │
       └──────────────┼──────────────┘
                      ▼
                Event Collector
                      │
                      ▼
                Local Database
                      │
                      ▼
              Activity Timeline
Enter fullscreen mode
Exit fullscreen mode
A simple event model could be:
{
timestamp
:
Date
.
now
(),
type
:
"
network
"
,
app
:
"
docker
"
,
downloadBytes
:
1824000
,
uploadBytes
:
420000
}
Enter fullscreen mode
Exit fullscreen mode
Or:
{
timestamp
:
Date
.
now
(),
type
:
"
power
"
,
state
:
"
sleep
"
}
Enter fullscreen mode
Exit fullscreen mode
Or:
{
timestamp
:
Date
.
now
(),
type
:
"
application
"
,
app
:
"
Code
"
,
window
:
"
server.js - Visual Studio Code
"
}
Enter fullscreen mode
Exit fullscreen mode
Now everything becomes queryable.
The Interesting Part: Correlation
This is where a normal system monitor becomes a
desktop observability tool
.
Suppose we see:
18:20  User idle
18:23  CPU 65%
18:24  Network 18 MB/s
18:26  Docker active
18:31  420 MB downloaded
18:42  Screen locked
18:45  Network still active
19:02  System sleep
Enter fullscreen mode
Exit fullscreen mode
We can generate an explanation:
Docker continued running after the user became idle and transferred approximately 420 MB before the system entered sleep.
That's an insight.
Not just a metric.
A Simple Collector
We could start with something surprisingly small:
const
{
powerMonitor
}
=
require
(
"
electron
"
);
const
si
=
require
(
"
systeminformation
"
);
async
function
collect
()
{
const
[
cpu
,
memory
,
network
]
=
await
Promise
.
all
([
si
.
currentLoad
(),
si
.
mem
(),
si
.
networkStats
()
]);
return
{
timestamp
:
Date
.
now
(),
system
:
{
idle
:
powerMonitor
.
getSystemIdleTime
(),
idleState
:
powerMonitor
.
getSystemIdleState
(
60
),
battery
:
powerMonitor
.
isOnBatteryPower
()
},
cpu
:
cpu
.
currentLoad
,
memory
:
{
active
:
memory
.
active
,
total
:
memory
.
total
},
network
:
network
.
map
(
n
=>
({
interface
:
n
.
iface
,
rxPerSecond
:
n
.
rx_sec
,
txPerSecond
:
n
.
tx_sec
}))
};
}
setInterval
(
async
()
=>
{
console
.
log
(
await
collect
());
},
5000
);
Enter fullscreen mode
Exit fullscreen mode
Five seconds later, we have the beginning of our own desktop telemetry system.
But Don't Collect Everything Every Second
This is an important design decision.
You don't necessarily want:
Every 1 second
    ↓
Everything
    ↓
Database
Enter fullscreen mode
Exit fullscreen mode
That can generate enormous amounts of useless data.
Instead, use different collection intervals.
Power events        Event-driven
App changes         Event-driven
CPU                 5-10 seconds
Memory              10 seconds
Network             1-5 seconds
Connections         10-30 seconds
Daily aggregates    1 minute+
Enter fullscreen mode
Exit fullscreen mode
And store
state changes
rather than repeated identical states.
For example, don't write:
10:00 VS Code
10:01 VS Code
10:02 VS Code
10:03 VS Code
10:04 VS Code
Enter fullscreen mode
Exit fullscreen mode
Store:
VS Code
10:00 → 10:04
Duration: 4 minutes
Enter fullscreen mode
Exit fullscreen mode
This makes the database dramatically smaller.
What About Electron's Network Logging?
If the thing you're monitoring is specifically
your Electron application's own network traffic
, Electron has another useful tool:
netLog
.
const
{
app
,
netLog
}
=
require
(
"
electron
"
);
app
.
whenReady
().
then
(
async
()
=>
{
await
netLog
.
startLogging
(
"
/tmp/electron-network-log
"
);
});
Enter fullscreen mode
Exit fullscreen mode
Electron's
netLog
records network events for a session and supports different capture modes. Be careful with
includeSensitive
and
everything
, because those modes can capture sensitive information or transferred bytes.
This is different from
systeminformation
:
systeminformation
        ↓
Whole-system information

Electron netLog
        ↓
Your Electron application's network activity
Enter fullscreen mode
Exit fullscreen mode
That distinction is important.
The Product I Would Build
I wouldn't call this another "Task Manager."
I'd call it something like:
Desktop Observability
The dashboard could have four major views.
1. Activity
VS Code       4h 12m
Chrome        2h 31m
Slack         58m
Docker        1h 42m
Enter fullscreen mode
Exit fullscreen mode
2. Network
Download     8.4 GB
Upload       1.3 GB

Docker       3.1 GB
Chrome       2.7 GB
VS Code      1.2 GB
Enter fullscreen mode
Exit fullscreen mode
3. Power
Active       8h 21m
Idle         1h 08m
Sleep        7h 42m

Battery used 34%
Enter fullscreen mode
Exit fullscreen mode
4. Timeline
09:02  Wake
09:05  VS Code
10:32  Chrome
12:14  Idle
12:31  Docker network activity
13:02  Active
18:42  Lock
19:01  Sleep
Enter fullscreen mode
Exit fullscreen mode
And then the killer feature:
Ask the computer
Why was my laptop slow today?
What used the most bandwidth?
What happened while I was away?
Which applications are active in the background?
Did anything continue running after I locked the computer?
The Architecture
A practical first version could be:
Electron
│
├── Main Process
│   │
│   ├── powerMonitor
│   ├── systeminformation
│   ├── active-window
│   └── netLog
│
├── Collector
│   │
│   ├── power events
│   ├── app sessions
│   ├── CPU/memory
│   └── network stats
│
├── SQLite
│
└── React Renderer
    │
    ├── Dashboard
    ├── Timeline
    ├── Applications
    ├── Network
    └── Power
Enter fullscreen mode
Exit fullscreen mode
The key design principle is:
Collect locally. Correlate locally. Explain locally.
You don't need to send a user's entire computer activity to a cloud server just to tell them why their laptop was busy.
The Bigger Idea
The interesting thing here isn't
systeminformation
.
It isn't Electron's
powerMonitor
.
It isn't network monitoring.
It's the
combination
.
A computer is already generating thousands of signals:
Applications
Processes
CPU
Memory
Network
Power
Sleep
Wake
Idle
Lock
Unlock
Enter fullscreen mode
Exit fullscreen mode
Today, these signals are mostly presented independently.
A desktop observability layer could connect them.
And instead of asking:
"What's my CPU usage?"
we can finally ask:
"What happened on my computer while I wasn't looking?"
That's a much more interesting monitoring problem.