Enterprise Network
Monitoring.
Free.

Each target card shows a complete real-time snapshot. Cards update on every ping cycle (default every 60 seconds). The left border colour and status dot use the same colour system as the app's tray icon.

The right-hand column on the Dashboard shows the Recent Alerts feed when no target card is selected. It displays the last 50 alerts in reverse-chronological order. Each item is colour-coded by severity. Clicking a target card hides the feed and replaces it with the Target Detail analytics panel — the Back button restores the feed.

On first run (or when no config file exists at C:\packetmonitor\config.json), the app opens directly on the Settings screen rather than the Dashboard. Once the user navigates to Dashboard, an amber banner is shown until all three requirements are met.

Clicking any target card swaps the right-hand column from the Alerts feed to the full Target Detail analytics panel. The panel contains a latency trend chart, loss heat strip, jitter/availability metrics, and all last-known diagnostic output from the Auto-Recon run. A Back button restores the alerts feed.

Runs tracert -d {host} — the -d flag skips reverse DNS lookups for speed. Maps every hop from the monitoring machine to the target, showing the latency at each hop. Identifies exactly which router or transit segment introduced the latency or loss.

Runs pathping -n -q 50 {host}. Unlike tracert, pathping sends 50 packets per hop and reports the loss percentage at each individual hop — not just end-to-end. This pinpoints exactly which router is dropping packets. The -n flag skips DNS. Takes up to 6 minutes for accurate results so it runs concurrently with the alert email.

Runs arp -a to dump the local ARP table. This is most useful for detecting duplicate IP address conflicts — a common but hard-to-spot cause of intermittent packet loss. If two devices share an IP, the ARP table will show MAC address flapping. The full ARP output is included in the alert email and displayed in the diagnostics expander.

Runs nslookup {host} against the system's configured DNS server. This confirms whether the DNS is resolving correctly at the time of the alert. A failed or slow DNS lookup can cause connection issues that look like packet loss but aren't. Output is included in the alert email.

Attempts a TCP socket connection to five standard ports on the target — all run concurrently. Results appear as OPEN / CLOSED badges in the alert email and in the Target Detail panel. This quickly reveals whether the device's services are still responding even when ICMP is degraded.

Alert emails are fully styled HTML messages generated by MailKit. They render correctly in all major email clients (Outlook, Gmail, Apple Mail). The email is self-contained — no images loaded from external URLs.

Each target has an independent alert cooldown timer. After an alert email is sent for a target, that target cannot trigger another email until the cooldown expires — even if the threshold remains breached for multiple consecutive checks. This prevents email floods during sustained outages.

A global hourly cap prevents the monitor from overwhelming your SMTP relay or inbox during a widespread network outage that affects many targets simultaneously. The count is tracked using a sliding window queue — exactly how many emails were sent in the last 60 minutes.

The Settings screen includes a "Send Test Email" button that fires a plain-text test message to all configured recipients using the current SMTP configuration — without requiring a real threshold breach. Use it immediately after entering SMTP credentials to verify the relay is working before deploying to production.

A canvas-drawn polyline chart showing average latency over the 120-point rolling history window (~2 hours at default 60s interval). The chart redraws automatically on each new ping cycle without any user interaction.

A horizontal row of 120 colour-coded rectangles — one per ping check in the rolling history buffer. The colour encodes packet loss for that individual check. The visual pattern immediately reveals whether loss was sustained, intermittent, or a single spike.

Two computed analytics are shown in the stats bar of the Target Detail panel, updated on every new ping cycle.

The Force Recon button in the Target Detail Panel header triggers an immediate full diagnostic sweep on demand — without needing a threshold breach. The spinner appears while diagnostics run, and results update the collapsible expanders (Traceroute, Pathping, ARP, DNS, Ports) when complete.

Each target slot is assigned one of 8 distinct colours from a fixed palette, assigned in order. That colour is used consistently across the checkbox selector, overlaid latency chart polylines, loss strip labels, and stats table header dots — so you always know which line belongs to which target at a glance.

All selected targets are drawn on a single canvas chart with a shared global y-axis scale. This makes latency spikes on different targets directly comparable — if two lines spike at the same time point, they were degraded simultaneously.

Below the latency chart, each selected target gets its own labelled loss heat strip stacked vertically. The label uses the target's palette colour, making it trivial to align which strip belongs to which target. Vertical alignment is the key insight: if two strips both show red blocks in the same horizontal position, both targets degraded at the same time.

The correlation engine scores simultaneous degradation between every pair of selected targets. For each pair, it counts how many check cycles both were degraded at the same time, divided by the total checks where either was degraded. The pair with the highest score is shown in the Correlation Banner.

A dynamic grid table with one column per selected target and one row per metric. Column headers use the target's palette colour. All cells are colour-coded by health — the worst columns are visually obvious at a glance.

The About tab contains a Windows Service card that lets you fully manage the MatrixITPktMon service without ever opening a command prompt. All operations that require elevation (install, remove) launch an elevated subprocess automatically via RunElevated() — a UAC prompt appears once per operation.

A named Mutex prevents multiple GUI instances from running simultaneously. When the desktop shortcut is clicked a second time (or the EXE is double-clicked), the new process detects the Mutex is already held, finds the existing window using P/Invoke, restores it from the tray, brings it to the foreground, and exits immediately. No duplicate windows ever appear.

When started with the --headless flag (which the service wrapper uses automatically), the app bypasses all GUI initialization and calls ServiceBase.Run(new WindowsServiceHost()). The WindowsServiceHost starts MonitorService on OnStart and cancels it on OnStop. SCM marks the service as RUNNING immediately after OnStart returns.

The app renders a custom tray icon with a dynamic status-coloured dot overlaid on the base app icon. The dot colour reflects the worst status across all monitored targets — green if everything is OK, amber if any target is WARNING, red if any is ALERT. The icon updates after every monitoring cycle.