Generated page. Written from IdaMilk/SunDown at commit c0b7e9b on 2026-07-28, version 1.0.0.
SunDown
What is it?
A self-hosted uptime monitor for the internal network — a Down Detector for services you own. It continuously checks internal services, devices and web apps, opens an incident automatically when something goes down, closes it on recovery, and emails at each transition.
Purpose
Internal services fail quietly. Without monitoring, the first signal is usually someone on the plant floor saying an app is not working, by which point the outage has already cost time.
SunDown provides that signal, plus an incident history — which turns "it feels like this keeps breaking" into something you can actually look at.
How it Works
An Express server with a scheduler (server/scheduler.js) running checks on a cron cadence. Each check type is its own module under server/checks/, so adding a protocol means adding a file.
| Check | What it verifies |
|---|---|
| ICMP ping | Host reachability |
| DNS | Name resolution |
| TCP port | A port is accepting connections |
| HTTP / HTTPS | An endpoint responds as expected |
| TLS certificate expiry | A certificate is not about to lapse |
The certificate expiry check is the one that earns its keep quietly — it catches the outage that has not happened yet.
State transitions drive everything: when a check flips from healthy to failing, an incident opens and an email goes out; when it recovers, the incident closes and another email goes out. Incidents are logged rather than merely alerted, so the history survives.
The front end is plain JavaScript components served from public/ — no build step, no framework. Data lives in SQLite via better-sqlite3, which means no database server to run alongside it.
Core Features
| Feature | Purpose |
|---|---|
| Multi-protocol checks | Ping, DNS, TCP, HTTP/HTTPS, TLS expiry |
| Automatic incident lifecycle | Opens on failure, closes on recovery |
| Incident log | Historical record with manual add/edit |
| Email notification | Alerts on each state transition |
| Dashboard | Service cards with current state |
| Service detail | Per-service history |
| Settings | Check intervals, SMTP, thresholds |
| Authentication | Session-based login, bcrypt hashed |
Tech Stack
| Technology | Version | Purpose |
|---|---|---|
| Express | ^4.19.2 | HTTP framework |
| better-sqlite3 | ^12.9.0 | Embedded database |
| node-cron | ^3.0.3 | Check scheduling |
| nodemailer | ^6.9.13 | Email alerts |
| ping | ^0.4.4 | ICMP checks |
| axios | ^1.7.2 | HTTP checks |
| express-session | ^1.18.0 | Sessions |
| bcryptjs | ^2.4.3 | Password hashing |
| dotenv | ^17.4.2 | Configuration |
Node 18 or higher, tested on Node 24. Vanilla JavaScript front end — no framework or bundler.
Operations
Docker is the intended deployment: Dockerfile, docker-compose.yml and docker-entrypoint.sh are all present, and the README leads with the Docker path. Running directly under Node is supported too.
Configuration comes from environment variables, documented in .env.example — SMTP settings, session secret and check defaults.
SQLite means the database is a file. Backups are a file copy, and the db/ volume is the thing to persist when running in Docker; losing it loses the incident history.
docs/superpowers/ contains the design spec and plan from the dockerisation work, so the reasoning behind that change is recorded alongside the code.
Repository
| Repository | IdaMilk/SunDown |
| Version | 1.0.0 |
| Primary language | JavaScript (Node) |
| Files | 35 |
| Last activity | 2026-04-29 |
| Status | Active |
Written as a general-purpose tool rather than something Suntado-specific — the README addresses "your internal network", not Suntado's. It would stand alone as an open-source project.