Network Monitor
Real-time network health dashboard
In plain English
A live dashboard showing whether your internet connection is healthy right now — speed, delays, and dropped data — updating every second.
My role
Solo developer
Timeline
4 weeks
Team
Solo
Status
Open source
Section 01
The problem
Diagnosing an unstable connection with periodic speed tests tells you almost nothing. The failures that matter are brief spikes and momentary packet loss, which a test you run once an hour will always miss.
Section 02
How I approached it
Continuous sampling pushed to the browser over a WebSocket, rendered as live time-series charts so intermittent problems become visible as they happen rather than as an average that hides them.
Outcome
Transient network problems become observable instead of anecdotal.
Section 03
Going deeper
Why polling fails here
HTTP polling forces a tradeoff: poll often and waste requests, or poll rarely and miss events. A persistent WebSocket connection lets the server push each sample the moment it exists, which is the only way sub-second resolution stays practical.
Rendering a moving window
Charts that update several times a second will destroy frame rate if handled naively. Data is kept in a bounded rolling buffer and rendering is decoupled from data arrival so the UI stays smooth.
Section 04
The build process
Pick the metrics
Latency, jitter, packet loss, and throughput — the four numbers that actually explain a bad connection.
Build the streaming layer
WebSocket server pushing samples with reconnection handling on the client.
Make the charts survive
Bounded buffers and render throttling so continuous updates don't melt the browser.
Section 05
How the pieces fit together
Each layer has one job. Read it top to bottom — that's roughly the path a request takes through the system.
Next.js dashboard
Live charts with a rolling time window and reconnection handling.
WebSocket server
Pushes each measurement sample the instant it is captured.
Sampling loop
Continuous latency, loss, and throughput measurement.
Section 06
What it does
Sub-second updates
Samples arrive as they are measured, not on a polling interval.
Rolling time window
Recent history stays visible so spikes have context.
Automatic reconnection
The client recovers cleanly when the connection itself drops.
Section 07
The hard parts
Render performance
High-frequency updates required decoupling data ingestion from chart rendering.
Measuring honestly
The monitoring itself consumes bandwidth, so sampling had to stay light enough not to distort what it measures.
Section 08
What I took away
- Resolution matters more than accuracy when diagnosing intermittent faults.
- Real-time UIs need backpressure at the render layer, not just the network layer.
Transport
WebSockets
Metrics
Latency, loss, bandwidth
Update rate
Sub-second
UI
Live charts
Let's build something worth shipping
Available for freelance projects, full-time roles, and technical consulting. Tell me what you're building and I'll tell you honestly whether I'm the right person for it.
Based in Rio de Janeiro, Brazil · Working with teams in any timezone · Fluent in English and Portuguese