OneUptime is an open-source, self-hostable monitoring and observability platform written in TypeScript and released under the Apache-2.0 licence, built for DevOps, SRE, and on-call teams that want uptime checks, incident response, status pages, logs, traces, metrics, and APM in one application instead of a shelf of separate SaaS subscriptions.

What it is

OneUptime lives in the Infrastructure & Operations / Monitoring & Observability category. It is a single TypeScript application that combines multi-region uptime monitoring, alerting and on-call scheduling, incident management, public and private status pages, log management, error tracking, distributed traces, metrics, and APM dashboards. The project has 7,611 stars, 453 forks, and 292 open issues, and legal, technical, and documentation material is published in English alongside translations in Simplified Chinese, Traditional Chinese, Japanese, Korean, Spanish, French, German, Portuguese, Italian, Russian, Hindi, Persian, Dutch, Danish, Swedish, and Norwegian.

The concrete problem is tool sprawl. Teams typically run Pingdom or UptimeRobot for uptime checks, StatusPage.io for public status, PagerDuty or Opsgenie for on-call paging, Incident.io for incident workflow, Datadog or New Relic for APM and metrics, Loggly for logs, and Sentry for error tracking — seven products, seven bills, and no shared context between an alert and the trace that explains it. OneUptime replaces that set with one self-hostable app, so detection, paging, status communication, and root-cause correlation happen in the same system rather than across vendor boundaries.

Key capabilities

• Multi-region uptime checks covering website, API, ping, port, SSL, DNS, and synthetic monitors, with automatic incident creation when a latency threshold such as 5s is breached.
• Public and private branded status pages with email and SMS subscribers that update automatically when an incident changes.
• On-call scheduling and alerting with escalation policies delivering SMS, phone call, push, and Slack notifications, escalating to backup until someone acknowledges.
• Incident management for declaring, triaging, communicating, and writing post-mortems.
• APM, metrics, and dashboards, including trace waterfalls that correlate traces, logs, and metrics down to the exact span.
• Log management and error tracking: collect, search, and alert on logs, and capture exceptions with full stack traces and context.
• An AI agent that opens a pull request with a proposed fix, linked to the incident and verified against the repository's configured build and test commands before the PR is opened.

Who uses it and how

• Homelabs and small teams run the whole stack from Docker Compose on a single Debian, Ubuntu, or RHEL server; a Raspberry Pi is sufficient.
• On-call rotations use escalation policies per policy area, for example a Payments policy that calls, texts, and push-notifies the on-call engineer and escalates to backup automatically.
• Teams consolidating vendor spend deploy it to replace separate uptime, status page, paging, incident, APM, log, and error-tracking subscriptions.
• SRE and DevOps teams use the correlated trace waterfall to find root cause, such as a slow SELECT … FOR UPDATE on orders stuck on a missing index.
• Teams without infrastructure to operate can use OneUptime Cloud instead of self-hosting.

Getting started

Two paths are documented: sign up for the hosted OneUptime Cloud free-forever plan with no credit card, or self-host with Docker Compose by cloning the release branch, copying config.example.env to config.env, setting strong random secrets, and running npm start, after which the platform is reachable at http://localhost. Self-hosting requires a Debian, Ubuntu, or RHEL host with Docker and Docker Compose installed.

How it compares

Against Pingdom and UptimeRobot for uptime, StatusPage.io for status pages, PagerDuty and Opsgenie for on-call, Incident.io for incidents, Datadog and New Relic for APM, Loggly for logs, and Sentry for errors, OneUptime is Apache-2.0 licensed and free to self-host, while those alternatives are paid hosted products. Self-hosting places the monitoring data, incident history, and subscriber list on infrastructure the operator controls rather than in each vendor's tenancy, and collapses several recurring subscriptions into one system to run. The hosted cloud plan exists as an alternative for teams that would rather not operate that system themselves.

When to use it — and when not to

A self-hoster must run and maintain a Docker and Docker Compose host, edit config.env with strong random secrets, and keep the release branch updated, so the operational burden sits with the operator rather than a vendor. The project carries 292 open issues, which signals active development but also a real backlog, and the README reads as a narrative walkthrough rather than reference documentation, so plan to work from the docs site. Teams that need only simple uptime pings, or that want a zero-ops single-purpose tool, should not adopt the full stack — a narrower monitor or the hosted plan fits better than a self-hosted platform spanning seven product categories.

# 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 (then edit it — set strong, random secrets!)
cp config.example.env config.env

# 3. Start everything
npm start

helm repo add oneuptime https://helm-chart.oneuptime.com
helm install oneuptime oneuptime/oneuptime