OneUptime puts uptime checks, on-call paging, status pages and OpenTelemetry in one self-hostable product

The tool that detects the outage is the one that pages and posts

OneUptime's design argument is that detection, paging and customer communication belong in one product. Monitors check websites, APIs, ports, DNS and certificates from probes around the world or from inside your own network, and also watch servers, Kubernetes, Docker, VMware, databases and network devices. When a check fails, the incident is worked on one timeline, the on-call person is paged by phone, SMS, email, push, Slack or Microsoft Teams, and the page escalates until someone responds. The same incident can then be posted to a public or private status page, which also carries scheduled maintenance notices. Logs, metrics and traces arrive over OpenTelemetry, alongside exceptions, profiles, real user monitoring and security events. Workflows and runbooks automate routine work and connect to Jira and ServiceNow. The benefit is fewer integrations between separate tools; the cost is that one platform outage affects monitoring, paging and the status page together.

npm start randomises every secret in config.env

Self-hosting with Docker Compose needs a Linux server with at least 8 GB of memory, plus Docker, Docker Compose, Git and Node.js. Before starting, set HOST in config.env to the domain name or IP address people will use, without http://; leaving it at localhost is only for trying OneUptime on your own computer. The install itself is three steps:

# 1. Clone the release branch
git clone --depth 1 --single-branch --branch release https://github.com/OneUptime/oneuptime.git
cd oneuptime

# 2. Create your config
cp config.example.env config.env

# 3. Start everything
npm start

npm start checks the server, gives every secret in config.env its own random value and starts the stack. When it prints OneUptime is up!, open the server address and sign up. The first account to register becomes the instance admin, so register yourself before the address is reachable by anyone else.

Postgres listens on loopback port 5400 only

The Compose file starts app, probe and runner containers that wait for three healthy backing services: PostgreSQL, Valkey and ClickHouse. PostgreSQL is published only on the server's loopback address at port 5400, mapped to 5432 inside the container, so that npm run backup, restore.sh and psql work on the server itself while no other machine can reach the database. DATABASE_PUBLISHED_PORT in config.env moves it off 5400 when another program holds that port. The consequence is deliberate but worth knowing up front: an external BI tool, a remote backup job or a database admin on another machine cannot connect directly. You need an SSH tunnel, or the approach in the Back up and restore part of the Docker Compose guide. backup.sh and restore.sh sit at the repository root for the local path.

APP_TAG decides the edition you run

One variable in config.env switches editions. APP_TAG=release runs the Community Edition and APP_TAG=enterprise-release runs the Enterprise Edition, and the Compose file uses that tag for the oneuptime/app, oneuptime/probe and oneuptime/runner images. Images are pushed to both Docker Hub and the GitHub Container Registry; switching to GHCR means changing an image reference such as oneuptime/dashboard:latest to ghcr.io/oneuptime/dashboard:latest. The Community Edition is free and open source and includes everything in the feature list, SAML and OIDC single sign-on among them. The Enterprise Edition adds SCIM provisioning, audit logs, team compliance and instance health dashboards, with priority support, and production use of it needs a license from sales. An organisation whose security policy requires audit logs or SCIM therefore cannot meet it on the free edition.

Apache 2.0 with an exception for ee/

OneUptime is open source under the Apache License 2.0 except for the ee/ directory, and GitHub's license detection reports the repository as NOASSERTION rather than a single license. A NOTICE file sits beside the LICENSE at the root. If you plan to fork OneUptime or redistribute a modified build, the line between the Apache code and the ee/ tree is the one to check before you ship anything. The contributing guidelines in .github/CONTRIBUTING.md also explain how licensing works for pull requests, which matters before you send a patch upstream.

Three releases in about 29 hours

Releases arrive fast. 14.0.100 was tagged on 2026-11-02 at 08:44 UTC, 14.0.101 at 21:22 the same day, and 14.0.102 on 2026-11-03 at 13:50, which is also the version in the root package.json. The install clones the release branch with --depth 1, so each fresh install lands on whatever is current. For a self-hosted monitoring system that is a mixed blessing: fixes reach you quickly, but you are upgrading the thing that tells you when everything else breaks. Read the update section of the Docker Compose guide, or the upgrade notes in the Helm chart README, and decide on a cadence instead of pulling every tag.

Helm, Terraform and an MCP endpoint for automation

For production at scale or high availability the project points to its Helm chart, where host plays the same role as HOST in config.env:

helm repo add oneuptime https://helm-chart.oneuptime.com/
helm install my-oneuptime oneuptime/oneuptime --set host=oneuptime.example.com

The chart README in HelmChart/Public/oneuptime covers storage, HTTPS, databases and upgrades. Beyond the UI, monitors, status pages and on-call schedules can be managed from scripts and CI through the API, a CLI and Terraform, and the Examples folder includes an opentofu directory next to otel-dotnet, fluentd and log-collectors samples. An MCP server at https://oneuptime.com/mcp lets Claude, Cursor, VS Code with GitHub Copilot or other MCP clients query logs and traces, look into an incident, acknowledge an alert or set up a monitor. OneUptime AI investigates new incidents and alerts and posts a root cause analysis with citations, and only opens a pull request with a proposed fix when you turn fixing on.

Editorial conclusion

OneUptime suits teams that want monitoring, incident paging, status pages and OpenTelemetry logs, metrics and traces in one place instead of wiring four tools together, and that can run a Linux server with at least 8 GB of memory. Teams that need SCIM provisioning or audit logs in production should budget for an Enterprise license. Before deploying, set HOST correctly, register the admin account first, and decide how you will track releases that land several times a day.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes