# Pi.Alert: LAN device discovery and alerting on Debian, with a web UI > Pi.Alert scans your Wi-Fi and LAN on a five-minute cron cycle, alerts on unknown devices and disconnects, and checks web services. Here is how it installs, what it cannot do, and how it differs from NetAlertX. **leiweibau/Pi.Alert** — Scan the devices connected to your WIFI / LAN and alert you the connection of unknown devices. It also warns if a "always connected" device disconnects. In addition, it is possible to check web services for availability. For this purpose HTTP status codes and the response time of the service are evaluated. - Repository: https://github.com/leiweibau/Pi.Alert - Website: https://leiweibau.net - Stars: 1,207 · Forks: 99 - Language: PHP - License: GPL-3.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/leiweibau-pi-alert ## What Pi.Alert watches, and the person it is built for Pi.Alert answers a narrow question: has anything on my network changed since I last looked? According to the README, it discovers devices on Wi-Fi or LAN, notifies you when an unknown device appears or a known one goes offline, and also monitors internal and external web services by HTTP status, response time, and SSL certificate information. It can detect unwanted or foreign DHCP servers, which matters on flat home networks where a second router or a misconfigured access point can start handing out leases. The target user is someone running a small network on Debian, typically a Raspberry Pi, who wants a local dashboard rather than a cloud service. The README states the project was originally designed for the Raspberry Pi and targets Debian-based systems using apt. It is not a packet capture tool and not an intrusion detection system. It builds an inventory over time and tells you when that inventory changes. Device metadata (owners, locations, groups, notes) lives in the same interface, so the tool doubles as a record of what you own. ## The five-minute cron loop and the scan sources behind it The backend is normally started by the operating system's cron service every five minutes. That single sentence explains most of the design. Each run executes the configured scans and imports, stores their results, and sends notifications when relevant changes are detected. There is no long-running daemon and no event stream; state is whatever the last run wrote to the database. Discovery is not tied to one method. The README lists arp-scan for local network discovery, plus imports from Pi-hole 5 and 6, FRITZ!Box, MikroTik, UniFi, OpenWrt, AsusWRT, pfSense, OPNsense, and AdGuard Home. If you already run one of those, Pi.Alert can reuse its view of the network instead of scanning again. Devices outside the local subnet are handled with ICMP. The repository layout reflects this split: back/ holds the backend, front/ the web interface, db/ the database layer, config/ the settings, and install/ the two shell scripts referenced in the README. For anything the host cannot see directly, the companion Pi.Alert-Satellite project scans independently and sends results to an existing Pi.Alert instance, using arp-scan, Pi-hole 6, MikroTik, UniFi, OpenWrt, AsusWRT, pfSense, OPNsense, or AdGuard Home on its side. That is the intended answer to a second VLAN or a remote site, and it is a separate installation rather than a setting. ## Installing Pi.Alert on Debian and finishing the first start The README gives a single installer command, run as root. It fetches the install script from the repository and executes it, so the host needs wget and network access to GitHub. ```bash sudo bash -c "$(wget -qLO - https://github.com/leiweibau/Pi.Alert/raw/main/install/pialert_install.sh)" ``` Before running it on DietPi, Ubuntu Server, or another Debian-based distribution, the README points to distribution notes in docs/LINUX-DISTRIBUTIONS.md. Those notes exist because the installer assumes apt and a Debian layout, and the project says to check them first rather than after a failed run. When the installer finishes, the README directs you to the first-start guide in docs/FIRST_START_GUIDE.md. Login protection is enabled during installation with a randomly generated password, which you can change later with pialert-cli; the CLI is documented in docs/PIALERTCLI.md. The web interface is where you then review current and historical device information, add owners and locations, configure the frontend, and edit backend settings. If you want to drive it from another system, docs/API-USAGE.md covers integrations such as Home Assistant and Homepage. Updating is a second script, and the README says the Update Check entry in the sidebar shows available releases, their changes, and the status of the GeoLite2 database. ```bash sudo bash -c "$(wget -qLO - https://github.com/leiweibau/Pi.Alert/raw/main/install/pialert_update.sh)" ``` If your installation still uses the previous home-directory layout, the README says to follow the migration guide in docs/MIGRATION_HOME_TO_OPT.md instead of updating in place. ## What Pi.Alert will not do for you The cron cadence is the first limitation. A device that joins and leaves inside a five-minute window can be missed entirely, and the README does not describe any continuous monitoring mode to close that gap. Anything you need to catch in real time is the wrong fit for this architecture. Reachability is the second. Local discovery depends on arp-scan, which only sees hosts on segments the host can reach at layer 2. The README's answer to another network segment is Pi.Alert-Satellite, a separate deployment that sends results back. If you are not willing to run a second instance, the tool's coverage stops at the local subnet, with ICMP as the only mechanism for hosts beyond it. The third limitation is packaging. The README documents a shell installer for Debian-based systems and points to Proxmox VE Helper-Scripts for an LXC installation. There is no Docker or Docker Compose path described in the README, and the related searches for a Docker install have no corresponding instructions in the README. If your infrastructure is container-first, you would be adapting a system that expects apt, cron, and a writable installation directory. There is also a soft dependency on outside data. The Update Check sidebar entry reports the status of the GeoLite2 database, which is a separate download with its own update cycle. The README does not document rollback for a failed update, so a broken upgrade would be handled through the release archive at leiweibau.net, not through a documented revert procedure. ## Pi.Alert against NetAlertX and the original project The README names both alternatives directly. NetAlertX began as a Pi.Alert fork and is now an independent, Docker-based project. That is the real difference in approach: NetAlertX ships as a container, while this Pi.Alert is installed by a shell script onto a Debian host and runs its backend from cron. If your deployment model is Docker Compose, NetAlertX matches it and this project does not. pucherot/Pi.Alert is the original project, which the README describes as currently unmaintained. This repository is the maintained line, with a release on 2026-09-01 and a last push on 2026-09-03. The README also links to docs/VERSIONCOMPARE.md for a version-by-version comparison, which is the right place to look if you are migrating from the original rather than starting fresh. For a lighter-weight comparison, the search data pairs Pi.Alert with WatchYourLAN. The README does not describe WatchYourLAN, so the honest distinction to draw is scope: Pi.Alert combines device discovery with web service monitoring, DHCP server detection, Nmap scans, Wake-on-LAN, and network relationship mapping in one interface. A tool that only lists hosts does less than that, and the trade-off runs the other way too, since a smaller tool has fewer moving parts to keep running. ## Licence, maintenance, and the cost of staying current Pi.Alert is released under the GNU General Public License 3.0. For self-hosted use that changes little. If you plan to modify the code and distribute the result, or to bundle it into a product you ship, GPL-3.0 obligations attach to what you distribute. That is a description of the licence, not legal advice; read LICENSE.txt and talk to someone qualified if distribution is on the table. On maintenance, the last push was on 2026-09-03, and the most recent release is v2026-09-01, published the same day. Releases have arrived at irregular intervals, with v2026-05-07, v2026-08-14, and v2026-09-01 in the recent list, so the practical upgrade cost is a periodic re-run of the update script rather than a continuous pull. The README points to the release archive at leiweibau.net for older releases and their notes. The ongoing costs are the ones the README makes visible: keeping the GeoLite2 database current, watching the Update Check entry for release notes, and handling the home-to-opt layout migration if your installation predates it. None of these are large, but they are recurring, and they assume you are comfortable running shell scripts as root on the host that holds your network inventory. ## Conclusion Adopt Pi.Alert if you run a Debian-based host or an LXC container and want device discovery plus service monitoring in one web UI, with alerts through email, ntfy, Telegram, Pushover, or Pushsafer. Do not adopt it if you want a Docker image you can drop into an existing compose stack, or if you need coverage on a segment the host cannot reach from its own interface. Before committing, verify that arp-scan returns hosts on the subnet you care about, that the five-minute cron entry is actually running, and that you can log in with the randomly generated password from installation and change it through pialert-cli. ## FAQ ### What is Pi.Alert? It is a self-hosted tool that discovers devices on your Wi-Fi or LAN, alerts you when an unknown device appears or a known device disconnects, and monitors web services by HTTP status, response time, and SSL certificate information. It runs a backend from cron every five minutes and presents everything through a web interface. ### How do I install Pi.Alert? Run the installer as root on a Debian-based system: sudo bash -c "$(wget -qLO - https://github.com/leiweibau/Pi.Alert/raw/main/install/pialert_install.sh)". The README says to check the distribution notes first if you are on DietPi, Ubuntu Server, or another Debian-based distribution, and to continue with the first-start guide afterward. ### How do I set up Pi.Alert after installation? The README directs you to docs/FIRST_START_GUIDE.md once installation is complete. Login protection is enabled during installation with a randomly generated password, which you can change later with pialert-cli, documented in docs/PIALERTCLI.md. ## Sources - [leiweibau/Pi.Alert on GitHub](https://github.com/leiweibau/Pi.Alert) - [License: GPL-3.0](https://github.com/leiweibau/Pi.Alert/blob/main/LICENSE) - [Project website](https://leiweibau.net) - [README](https://github.com/leiweibau/Pi.Alert/blob/main/README.md) - [Releases](https://github.com/leiweibau/Pi.Alert/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leiweibau-pi-alert