Open Source UptimeRobot Alternatives

Uptime Kuma is a self-hosted monitoring tool with a reactive interface and a short path from install to first check. It watches the endpoints you care about and notifies you when one stops answering, without sending your monitoring data to a third party.

Checks can run as often as every 20 seconds, and the whole thing serves on a single port. It is a Node application, so it runs either as a container with a mounted volume or as a plain process kept alive by pm2.

What you can watch, and how you hear about it, covers most of a small fleet.

• Monitor types: web endpoints with keyword or JSON query checks, TCP, ping, DNS records, websockets, push, Docker containers and Steam game servers.
• Notifications: Telegram, Discord, Slack, Gotify, Pushover, email over SMTP, and more than ninety other services.
• Status pages: several of them, each mappable to its own domain.
• Certificates and proxies: certificate details and proxy support alongside a ping chart.
• Accounts: two-factor authentication, plus translations into many languages.

Docker Compose is the quickest install, though the container must not be backed by NFS storage. A non-Docker setup needs Node 20.4 or newer, Git and pm2, and runs on the major Linux distributions or on Windows 10 and Windows Server 2012 R2 upward. The BSDs, Replit and Heroku are not supported.

Checkmate checks whether your servers and sites are reachable and performing, records what it finds, and tells you when that changes. Frontend and backend live in the same repository, and the project has been stress-tested past a thousand active monitors without hitting a bottleneck.

The lifecycle is deliberately dull. A check runs, its result is stored with a response time, and recent results are weighed against the monitor's status change threshold. Only when that threshold is crossed does state flip, an incident open or close, and notifications go out, which is what stops one flaky response from waking anyone.

The monitor types and outputs cover most of a small fleet.

• Check types: uptime, Docker, ping, SSL, port, game server, page speed and JSON query monitoring.
• Hardware metrics: memory, disk, CPU and network, through the separate Capture agent, with per-mountpoint disk selection.
• Status pages: public pages in four themes, built from the monitors you already have.
• Notifications: email, webhooks, Discord, Slack, PagerDuty, Matrix, Rocket.Chat, Microsoft Teams, Telegram, Pushover and Twilio SMS.
• Maintenance windows: scheduled work that does not raise incidents while it runs.

Deployment is a Docker Compose file starting the application image next to MongoDB, which is required and deliberately not embedded in it. It is light enough for a Raspberry Pi 4 or 5, expects a reverse proxy in front of it for TLS, and the interface is translated into sixteen languages.

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.

OpenStatus puts status pages and uptime monitoring in the same tool, so the checks that detect an outage and the page that tells your users about it share one system. There is nothing to wire between a monitoring service and a separate status host.

Checks run from 28 regions in parallel across three cloud providers. The dashboard is a Next.js application, the API server runs on Hono, the checker is written in Go, and data lands in Turso through Drizzle with Tinybird handling analytics.

Everything the dashboard does is also reachable outside it.

• Status pages: custom domains, password protection, maintenance windows and subscriber notification by email and RSS.
• Monitoring: servers, websites and APIs watched from every region, with alerts through Slack, Discord, PagerDuty and email.
• Monitoring as code: YAML configuration driven from the CLI, GitHub Actions or Terraform.
• API: typed JSON over HTTP with a Node SDK, sharing a single key with the CLI.
• MCP server: connects an assistant such as Claude, ChatGPT or Cursor to your workspace.

Docker Compose is the fastest way to run it, and pre-built images cover the server, dashboard, status pages, workflows, checker and private locations, the last of these fitting in an 8.5MB image. Guides exist for one click deployment to Coolify and Railway, and the managed service charges a flat price with unlimited members.

OneUptime brings monitoring, alerting, incident response and observability into one application, so a team stops paying for a dozen products and stitching them together. It catches the outage, pages the right person, updates the status page and helps find the cause.

The platform maps directly onto the tools it displaces. Uptime monitoring covers website, API, ping, port, SSL, DNS and synthetic checks from probes around the world, while APM, metrics, log management and error tracking handle what happens once an alert has fired.

A single incident runs end to end inside the product.

• Detect: regional probes open an incident automatically when a threshold is crossed.
• Respond: on-call schedules and escalation policies call, text and push until someone acknowledges.
• Communicate: branded public and private status pages update themselves and notify subscribers by email and SMS.
• Diagnose: traces, logs and metrics correlate down to the individual span behind a slowdown.
• Auto-fix: an AI agent opens a pull request linked to the incident, verified against your configured build and test commands before you review it.

All of it is Apache 2.0 licensed. Self-hosting runs on a single Debian, Ubuntu or RHEL server with Docker and Docker Compose, cloning the release branch and filling a config file with your own strong secrets, and a Helm chart covers Kubernetes. A hosted cloud with a free tier funds the open source work for teams that would rather not operate it.

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.

Peekaping watches your websites, APIs, containers and databases from infrastructure you run, and tells you the moment something stops answering. It was written by people who used Uptime Kuma and wanted the same idea with an API underneath it and a typed, extensible codebase behind that.

The server is Golang, the frontend React and TypeScript, and storage is your choice of SQLite, PostgreSQL or MongoDB. The quickest start is a single Docker command with a SQLite volume, and a community Terraform provider exists for teams that manage monitors as code.

Coverage spans the checks and channels a mixed stack needs.

• Network monitors: HTTP and HTTPS, TCP, ping, DNS, push webhooks, Docker containers, gRPC and SNMP.
• Data layer monitors: PostgreSQL, Microsoft SQL Server, MongoDB, Redis, MySQL and MariaDB, plus MQTT, RabbitMQ and Kafka producers.
• Alert channels: email, webhooks, Telegram, Slack, Discord, Matrix, PagerDuty, Opsgenie, ntfy, Gotify, Pushover, Twilio and a dozen more.
• Status pages: public pages and SVG status badges for readers outside the team.
• Access control: multi-factor authentication, brute-force login protection, and API keys with rights management.
• SSL checks: certificate expiration is watched alongside availability.

Every function is reachable through the REST API, which is what makes it fit CI/CD pipelines and infrastructure as code tooling. The project is in beta and under active development, so the maintainer asks you to try it outside production first. Incidents, monitor groups and an Uptime Kuma migration tool are on the roadmap.

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.

EasyMonitor watches websites and APIs from hardware you control. Add a URL, pick an interval between thirty seconds and an hour, and get alerted when it breaks. Probes run in several regions so one flaky network path does not become a false alarm at three in the morning.

The application is Laravel with Livewire, and check results land in PostgreSQL with TimescaleDB as a hypertable. A scheduler pushes jobs onto Redis Streams, small Go probe binaries pull them, and a consumer writes results back, with Laravel Horizon giving ops a view of the queue.

The monitoring surface goes well past a plain up or down check.

• Check types: HTTP, ICMP and TCP port checks cover most of what a service exposes.
• Certificate expiry: SSL expiry is captured during HTTPS checks, with alerts thirty, fourteen and seven days out.
• Failure thresholds: a configurable run of consecutive failures is required before anyone is paged.
• Alert channels: email, Slack, Discord, Telegram, ntfy, Pushover and signed webhooks fire on both failure and recovery.
• Status pages: public, unlisted or private pages carry incidents, maintenance windows, custom themes and customer domains with automatic HTTPS.

Installation is a clone and an interactive script that asks about mode, domain, database, registration policy, mail driver and object storage before building the containers. Two gigabytes of RAM is enough to try it and four is comfortable in production, and remote probes reach the server over Tailscale or a tunnel rather than an exposed Redis port.

StatusScout watches the parts of a website that quietly break: an expiring certificate, a security header someone removed, a config file left readable, a subdomain pointing at nothing. It runs the checks on a schedule and sends an alert when something changes, so the discovery does not happen through a customer.

The repository is a workspace monorepo. A Fastify REST API serves the React dashboard and the public scan page, a cron package triggers periodic checks, a background worker executes them, and shared utilities handle notifications and issue history. MongoDB and Redis sit behind it, and Docker Compose starts everything at once.

The checks cover more ground than uptime alone.

• Certificates: SSL and TLS validity is tracked and flagged before it lapses.
• Headers and cookies: security headers, cookie settings, mixed content and general page security are inspected.
• Exposure: sensitive files, hidden paths and exposed API documentation are hunted using bundled wordlists.
• DNS: subfinder discovers subdomains and subzy checks them for takeover.
• Browser flows: Playwright Chromium drives custom flow checks against real pages.
• Broken links: dead links are reported alongside the security findings.

The quick path needs only Docker and Docker Compose; development also wants Node.js 20 or newer, local MongoDB and Redis, and the Go tools and Chromium above, without which the DNS and flow checks fail gracefully. The license is source-available, free for personal and commercial self-hosted use, with reselling it as a hosted service restricted.