winget install --id=MudabbirulSaad.NetPulse -e NetPulse monitors HTTP endpoints and DNS A queries through a selected resolver, displays accessible health states and real latency, and retains a short local history.
NetPulse is a compact Windows network-health dashboard built with C# and WPF. It monitors HTTP endpoints and explicit DNS resolvers, presents real latency and accessible health states, and keeps a short local history without accounts, telemetry, or a cloud service.
| State | Meaning |
|---|---|
| Healthy | HTTP 2xx/3xx, or a DNS A response containing at least one address |
| Degraded | HTTP 4xx/5xx, or a DNS resolver response such as NXDOMAIN |
| Offline | Timeout, name resolution, socket, connection, or TLS transport failure |
| Error | Invalid target configuration or an unexpected internal failure |
Every state uses text and an icon as well as colour.
NetPulse 1.0.0 targets Windows x64 and requires the Microsoft .NET Desktop Runtime 10 x64. Download NetPulseSetup.msi and NetPulseSetup.sha256 from the latest GitHub release, compare the checksum, then run the MSI as an administrator.
The installed application lives under %ProgramFiles%\NetPulse. Settings, history, and logs live under %LocalAppData%\NetPulse and remain after uninstallation. See the deployment checks and retention policy for the exact behavior.
Target names are 1–60 characters. HTTP targets accept absolute http or https URLs. DNS targets accept an internationalized domain name and an IPv4 or IPv6 resolver address. Polling can be 5, 10, 30, or 60 seconds; timeout must be 1–30 seconds and shorter than the polling interval. The dashboard accepts at most 25 targets.
More detail is available in the usage guide and common-problems guide.
Prerequisites:
global.jsondotnet tool restore
dotnet restore NetPulse.sln -p:Platform=x64
dotnet build NetPulse.sln -c Release --no-restore -p:Platform=x64
dotnet test NetPulse.sln -c Release --no-build --no-restore -p:Platform=x64
The deterministic suite contains 104 tests across core, infrastructure, and WPF view-model behavior. Real-network checks are opt-in with NETPULSE_RUN_NETWORK_TESTS=1 and do not run in ordinary CI.
Build and inspect the MSI:
dotnet build installer\NetPulse.Setup\NetPulse.Setup.wixproj -c Release -p:Platform=x64
pwsh -NoProfile -File scripts\installer\Test-NetPulsePackage.ps1
The Windows workflow builds, tests, publishes, packages, inspects, hashes, and uploads the release artifacts. Dependabot tracks NuGet and workflow dependencies.
The WPF application depends on one app-facing module, INetPulseSession. The core owns target rules, immutable state, scheduling, and metrics; infrastructure owns HTTP, DNS, ICMP, JSON, and logging adapters. This keeps the UI unaware of network libraries and storage details.
NetPulse makes only the network requests configured in the target list. It does not transmit analytics, create user accounts, or send settings/history/logs elsewhere. Logs exclude target names, URLs, resolver domains, query strings, credentials, and exception messages. See the complete privacy statement.
https://openreels.app is only a low-frequency public demonstration target. NetPulse does not import, modify, deploy, or require access to OpenReels source code, credentials, databases, APIs, DNS records, or infrastructure.
Version 1.0 deliberately omits tray mode, alerts, TLS certificate monitoring, authentication, a cloud backend, and other expansion features. The goal is a reliable, explainable desktop utility.