Deploy a self-hosted status page with endpoint monitoring and automatic HTTPS in minutes, with no external dependencies required.
Statusnook is a self-hosted status page and HTTP endpoint monitoring tool written in Go. It is designed for small teams, SaaS operators, and solo developers who want full control over their incident communication without paying for a managed service. The entire application ships as a single binary or Docker image that handles its own TLS certificate provisioning via Let’s Encrypt, stores all data in an embedded SQLite database, and serves both the public status page and the admin UI from one process.
Unlike most monitoring stacks that require assembling multiple services — a database, a web server, a notification router, a certificate manager — Statusnook collapses all of these into a single deployable unit. You can be up and running on a $5 VPS with automatic HTTPS in under five minutes using the one-line installer, or deploy via Docker Compose if you prefer container management. One-click templates for DigitalOcean, Vultr, Railway, and Zeabur are also available.
Monitors can be configured with any HTTP method, custom request headers and bodies, timeout thresholds, and retry attempts. When a monitor fails, alerts are delivered via Slack webhooks or SMTP email — including support for mail groups that route notifications to different teams. Subscribers can also sign up for public email alerts directly from your status page. Configuration can be managed through the web UI or via a YAML file pushed through GitHub, enabling GitOps-style configuration management.
Architecture Statusnook’s entire application logic — HTTP routing, request handlers, database access, TLS certificate management, DNS resolution, background monitoring goroutines, and cryptographic utilities — lives in a single 19,000-line Go file with no internal package decomposition. Chi is used as an HTTP router with inline middleware closures for session validation and CSRF protection, but the handlers themselves execute SQL queries directly against a shared database transaction without any service or repository layer in between. Background monitoring and notification delivery run as goroutines launched from main() sharing the database handle via closures. The design is a deliberate trade-off: the single-binary deployment model is maximally simple to operate, but the architecture makes unit testing essentially impossible and any extension requires modifying the central file.
Tech Stack Statusnook is written in Go 1.22 and compiled as a CGO-enabled binary due to its SQLite dependency via mattn/go-sqlite3. The HTTP layer uses the chi router on top of standard net/http. All HTML is rendered server-side with Go’s html/template package; HTMX provides lightweight client-side interactivity without a JavaScript build step. TLS automation is powered by CertMagic backed by Let’s Encrypt ACME, with a lightweight DNS server from miekg/dns handling DNS-01 ACME challenges entirely in-process. Secrets in YAML config are encrypted with AES-GCM. The application ships via a shell installer, Docker image (with multi-stage build), standalone binaries, and one-click marketplace templates for DigitalOcean, Vultr, Railway, and Zeabur.
Code Quality The repository contains no test files — the codebase is entirely untested at the automated level. Error handling is inconsistent: some errors are logged and the handler continues silently, while others propagate with fmt.Errorf wrapping but no custom error types or domain-specific context. No linting or static analysis configuration is present. The CGO dependency on mattn/go-sqlite3 introduces cross-compilation complexity that is not documented for contributors. Despite these limitations, the code is readable at the function level, naming is mostly clear, and the embedded schema and migration files make the data model easy to audit. The operational documentation in the README and docs/ directory is comprehensive and accurate.
What Makes It Unique Statusnook’s most distinctive integration is embedding a full ACME DNS-01 challenge resolver using miekg/dns directly inside the application binary, enabling automatic TLS provisioning without requiring an external DNS API, Certbot, or a separate certificate management service. Combined with embedded SQLite migrations and a self-contained binary deployment model, this achieves zero-external-dependency operation that is genuinely uncommon in the status page space. The YAML config layer adds a slug-based rename primitive that allows operators to rename monitors, mail groups, and notification channels without breaking historical data or foreign key relationships — a practical detail that most self-hosted tools ignore.
Statusnook is released under the MIT License, which is one of the most permissive open-source licenses available. You are free to use it commercially, modify the source code, distribute it, and run it on customer-facing infrastructure without any licensing fees or copyleft obligations. There are no open-core restrictions, no feature gating behind a paid tier, and no telemetry or license key requirements. The entire codebase is available on GitHub under these terms.
Running Statusnook yourself means you are responsible for the host machine it runs on, including OS updates, network security, and storage. The application manages its own SQLite database in a local data directory and handles TLS certificate renewal automatically, so the operational surface is small compared to multi-service alternatives. You will need to open ports 80 and 443 on your server for the standalone TLS mode, or run behind a reverse proxy like Caddy or NGINX if you prefer to manage certificates externally. Backup strategy is straightforward: the entire state is a single SQLite file that you can snapshot or copy. Updates can be applied in-app with one click, but you are responsible for scheduling maintenance windows.
There is no official managed cloud version of Statusnook, and no commercial support tier from the maintainer. This means you are trading the operational simplicity of a hosted SaaS (like Atlassian Statuspage or Better Uptime) for full data control and zero ongoing cost. If your status page has strict availability requirements, you will need to implement your own high-availability setup — the current architecture does not document multi-node or failover configurations. Community support is available via GitHub Issues, but response time depends on the two-person contributor base.