Open Source Instatus Alternatives

Cachet is the open source, self-hosted status page system. It gives a team its own place to report incidents and service health rather than renting a hosted product for the job.

The current 3.x line is a rebuild of the original project, with the reasoning and the roadmap set out in a discussion on the repository. It is a PHP application, and the installation and upgrade guides live on a separate documentation site rather than in the repository itself.

Standing up an instance comes down to a short list of pieces.

• PHP 8.3: the minimum runtime, with later releases supported.
• Composer: dependencies install through it, as in any modern PHP project.
• Database: MariaDB, MySQL, PostgreSQL and SQLite are all supported.
• Documentation: installation and upgrade instructions are published on the project's own docs site.
• Demo: a public 3.x dashboard with shared test credentials, reset every thirty minutes.

The demo is the quickest way to click through the dashboard before installing anything, since its login details are printed in the README and the instance clears itself twice an hour. Security vulnerabilities go to the maintainers by email and are reviewed case by case. Cachet suits teams already running PHP that want the status page under their own control.

Gatus is a health dashboard aimed at developers, and its README opens with the objection you would raise anyway. Why not use Alertmanager, CloudWatch or Splunk. The answer is that those rely on existing traffic, so if nobody is calling a broken endpoint, nothing fires and your clients find the outage before you do.

Gatus calls the endpoints itself on a schedule using HTTP, ICMP, TCP or DNS queries, then evaluates the result against conditions you write. A condition can test the status code, the response time, the body, the certificate expiration or the resolved IP address, which makes the same mechanism usable for automated user acceptance tests.

The design choices show up in daily use.

• Readable configuration: adding an endpoint to monitor is a short block of YAML, not a project.
• Alerting breadth: Slack, Teams, PagerDuty, Discord, Twilio, Telegram, Opsgenie and dozens more, plus custom providers.
• Low resource use: a Go binary small enough to sit in a cluster without anyone noticing it.
• Badges: uptime and response time badges served from the API for embedding elsewhere.
• Security options: basic authentication, OIDC, TLS encryption and exported metrics are all configurable.

Storage, maintenance windows, announcements, client behavior, tunneling and custom labels are configurable too, alongside experimental support for remote instances and an alpha suites feature for grouping related checks.

A single docker run command starts it on port 8080, which is enough to have real endpoints monitored within a minute. Its author runs it in a Kubernetes cluster watching his own core applications.

Kener puts up a clean status page without the weight of a full observability suite behind it. It is aimed at the team that needs to publish uptime and incident updates today and does not want to spend a week configuring Datadog or Atlassian tooling to do it.

The system is built with SvelteKit and Node.js, using shadcn-svelte for the interface. Its name comes from the Assamese word kene, meaning how is it going.

Monitoring, communication and administration all live in the same instance.

• Check types: API, ping, TCP, DNS, SSL, SQL, heartbeat and GameDig monitors.
• Incidents and maintenance: timelines, updates, acknowledgements and scheduled windows keep users informed.
• Notifications: alerts go out by email, webhook, Slack and Discord.
• Branding: logo, colors, custom CSS, themes, light and dark mode, localization and timezone-aware display.
• Team workflows: role-based collaboration, trigger-based workflows, template-driven messaging and API keys.
• REST API: programmatic access to incidents, monitors and reporting.

One instance can run several status pages, and embeddable widgets and badges push status into other sites. Deployment is a Docker Compose file that starts Kener with Redis, and prebuilt images include subpath variants for serving under a path such as /status. Without Docker it needs Node.js 24.14 or later, Redis, and a secret key and origin set before the first start.

Statusnook puts a public status page and the monitoring behind it in a single binary. One install script gets an instance running with managed TLS, so a team can publish incident updates and start checking endpoints the same afternoon instead of wiring a monitoring service to a separate hosted page.

Configuration works two ways. The web interface covers everything by default, and the settings page can switch an instance to text-based configuration, where a YAML document defines general settings, mail groups, notification channels, monitors and services. That file is applied from the settings page or synchronized automatically on pushes to a chosen GitHub branch, and a rename directive exists because dropping or renaming a key is destructive.

Deployment paths are laid out for several environments.

• Standalone: one shell command with managed TLS, requiring ports 80 and 443.
• Reverse proxy: the same install behind Caddy or NGINX on a port you choose.
• Docker: a published image run directly or through a compose file with a named data volume.
• Cloud templates: one-click deployments for DigitalOcean, Vultr, Railway and Zeabur.
• Binaries: amd64 and arm64 Linux builds attached to each release.

Monitors are HTTP checks with a method, headers, body, frequency, timeout and retry count, and each one points at notification channels and mail groups. Channels can be SMTP providers such as Postmark, Amazon SES or Azure Communication Services, or a Slack webhook, and secrets inside the config file are stored encrypted. Managed subscriptions let visitors sign themselves up for updates.