NetAlertX Tracks Wi-Fi Device History: Windows 11 Docker Scanning Limits

What the writer did and found​

Bamisile suspected people were using his Wi-Fi without permission. He had changed the password several times and still saw slowdowns, and his router only listed devices connected at that moment. He installed NetAlertX, a self-hosted network monitoring tool, and left it running for a few days. He then checked the dashboard and found four devices he didn't recognize. Their IP and MAC addresses gave him what he needed to block them in the router's admin page.

This is a first-person account. I found no independent confirmation of the four-device count. The writer also admits that an unfamiliar device isn't necessarily a stranger. Odd device names and MAC address randomization can make identification hard. Treat "four unknown devices" as a lead to investigate, not proof of intruders.

How the history works​

NetAlertX's own documentation backs up the snapshot-versus-history distinction:

• The database has a Devices table that includes first-connection and last-connection timestamps, last known IP, and the plugin that discovered each device.
• An Events table collects connection and disconnection events. An Online_History table feeds the presence chart.
• A separate change log records what changed on a device, when, the old and new values, and the source. The source can be a discovery plugin such as ARPSCAN, NSLOOKUP or UNIFIAPI, or a manual user change.
• Retention is controlled by the DEV_HIST_DAYS setting. Setting it to 0 turns off change-log recording.

So "a history of every device that has ever connected" is a fair shorthand, with a limit. The tool records what its configured scanners observed, and only while it was running and scanning. A phone that joined your Wi-Fi at 3 a.m. while your laptop slept leaves no trace.

The Windows and Docker caveat​

The writer's recipe was:

1. Install Docker Desktop on Windows 11.
2. Download the NetAlertX project files from GitHub.
3. Open the Docker installation folder in Windows Terminal.
4. Run docker compose up -d.
5. Browse to [url]http://localhost:20211[/url].

He hit errors along the way and used Docker Desktop's built-in assistant, Gordon, to fix them. Bamisile reports that this worked. I couldn't verify that independently.

Opening the web interface proves the app is running. It doesn't prove the app can see your Wi-Fi devices. NetAlertX's Docker guide says the container must run on the host network. It also says you must set SCAN_SUBNETS unless you rely on other scanner plugins. The default ARPSCAN plugin needs at least one valid subnet and interface. The guide's sample command also adds the NET_RAW, NET_ADMIN and NET_BIND_SERVICE capabilities.

Windows complicates this. Docker's documentation says host networking is supported on Docker Desktop 4.34 and later, and requires enabling the feature in Settings. It also says the Docker Desktop host network feature works on layer 4, so protocols that operate below TCP or UDP aren't supported. ARP, the discovery method NetAlertX leans on, works below that layer. Docker also notes that only Linux containers are supported.

A third-party explainer adds that because Docker on Windows runs in a lightweight Linux VM, host mode attaches the container to the VM's network, not the physical machine's network. That is a secondary source, but it matches Docker's own warning. My reading is that ARP-based discovery from Docker Desktop on Windows may be incomplete, so you shouldn't assume it sees everything. The writer's own result may have worked through other means. His article doesn't say which scanners or settings he used.

Docker also says published ports are discarded in host network mode. If you copy a Compose file that combines host networking with port mappings, expect warnings or errors. Follow NetAlertX's current Compose examples rather than improvising.

A sanity check before you trust the dashboard​

1. Confirm your own phone, TV and PC all show up in the device list.
2. Check which scanner plugins are loaded and what subnet they scan.
3. Keep scanner schedules consistent. NetAlertX recommends the same interval for all plugins that discover devices, because mismatched intervals can produce misleading notifications.
4. Wait for the first scan. The Docker guide says initial discovery can take 5 to 10 minutes.
5. If known devices are missing, don't conclude your network is clean. Move the install to a better-placed host.

For reliable monitoring, the writer himself says NetAlertX works best on something always on, such as a mini PC, Raspberry Pi or NAS. A laptop that sleeps will miss devices. The documentation also offers other install routes, including a bare-metal method it calls experimental, and the writer notes Unraid and Home Assistant options. A Linux host attached directly to your LAN avoids the Docker Desktop VM question entirely.

Alerts and plugins​

NetAlertX can push notifications, but you have to set that up. The plugin documentation lists publishers including email, Telegram, NTFY, Pushover, Pushsafer and webhooks. It also lists an Apprise plugin that works as a proxy for over 80 notification services. That figure comes from the NetAlertX plugin overview. I'm quoting only the "80" claim from it. Alerts won't flow until you load a publisher and enter its credentials.

You can also tune alerts per device, per plugin or globally. The writer recommends this to avoid fatigue from familiar devices reconnecting. Don't read "the moment a new device joins" as a guarantee. Timing depends on your scan interval.

Plugins are the tool's other main feature. The documentation lists device scanners, name-discovery tools, importers and publishers. Importers include Pi-hole, UniFi, AsusWRT, OpenWRT and others. Imported data reflects what that source reports. A router import is not the same as an independent scan. It also inherits any blind spots in that source.

The project also looks active. The release notes I reviewed show a switch to calendar-style versioning, a per-device change log and a new performance page. One recent note says existing installs using NMAPDEV may need to update their arguments to include --privileged. I can't tell which version the writer ran, so check the release notes for your own install.

What to do with an unfamiliar device​

1. Compare the MAC address against your own gear. Phones often use randomized MACs per network, so a "new" device may be a familiar one under a different address.
2. Look at the timestamps. A device seen once during a party tells a different story from one that appears nightly.
3. Block or review it in your router's admin interface, as the writer did.
4. If you're worried, change the Wi-Fi password and consider a guest network for visitors.

Bottom line​

NetAlertX turns the router's "right now" view into a record of what its scanners have seen over time. That is a real addition for home and small-office admins. But on Windows, host networking in Docker Desktop is a limited stand-in for the Linux version, so verify that known devices appear before you trust a clean dashboard. A bare-bones Docker setup on a sleeping laptop is better than nothing. An always-on Linux box with the right scanner configuration is what the tool is built for.