OneUptime

What OneUptime does

OneUptime tries to replace a whole set of separate services with one application. Its README lines it up against Pingdom and UptimeRobot for uptime checks, Statuspage for status pages, PagerDuty and Opsgenie for on-call, incident.io for incident management, Datadog and New Relic for APM and metrics, and Sentry for error tracking.

On the monitoring side it checks websites, APIs, IP addresses, ports, SSL certificates and DNS, and runs scripted synthetic monitors. When a check fails it can open an incident automatically, page whoever is on call according to schedules and escalation policies, and update a branded status page whose subscribers receive email or SMS. Incidents follow a workflow from declaration to post-mortem.

On the observability side it ingests logs, metrics and traces over OpenTelemetry, records exceptions with stack traces, and lets you build dashboards. Ready-made OpenTelemetry-based agents cover Linux, macOS and Windows hosts, Kubernetes (including eBPF traces and a service map), Docker and Podman, Proxmox, VMware, Ceph, Pure Storage arrays and common databases. A no-code workflow builder connects events to Slack, Jira, GitHub and Microsoft Teams, and an AI assistant looks for anomalies, suggests causes and can open a pull request with a proposed fix for you to review.

Probes and alerting

Checks are run by probes. OneUptime Cloud uses probes in several regions, so an outage can be confirmed from more than one place. A self-hosted installation runs its own probe workload, and you can add custom probes inside private networks or other locations; they only make outbound HTTPS connections and are reported as disconnected if they stop checking in. Self-hosted installations have no plan limits on probes. SMS and voice paging on a self-hosted instance go through your own Twilio account.

Self-hosting OneUptime

There are two supported installs: Docker Compose on a single Debian, Ubuntu or RHEL server, and an official Helm chart for Kubernetes. The stack needs PostgreSQL for configuration and state, ClickHouse for all telemetry, and Valkey (or any Redis-compatible server) for queues, cache and sessions; object storage is not required. For Docker Compose the documentation recommends 16 GB of RAM, 8 cores and 400 GB of disk, with 8 GB, 4 cores and 20 GB as a home-lab minimum. The Helm chart’s defaults set no resource limits and small volumes, and the sizing guide is explicit that they are not production values. ClickHouse accounts for most of the disk and memory, so retention settings drive the cost.

Community and Enterprise editions

Everything outside the ee/ directory is Apache-2.0, and the Community image contains no ee/ code. It includes monitoring, status pages, incidents, on-call, telemetry, workflows, the AI features, the API and Terraform, and also SAML and OIDC single sign-on. The Enterprise image adds SCIM provisioning, team compliance settings, audit logs, retention rules per signal or service, and administrator health dashboards, and needs a license priced by user seats for production use.

Hosted version

OneUptime Cloud runs the Enterprise Edition, with a free plan and paid plans; features such as SSO, SCIM, custom probes and audit logs depend on the plan.

Limitations

The breadth comes at a cost: a self-hosted OneUptime is a large deployment with three datastores, and each module is less specialized than a dedicated tool. Teams that only need uptime checks will find Uptime Kuma or Gatus far lighter, and teams focused on deep APM may prefer SigNoz.

Who it suits

OneUptime suits small and mid-sized engineering teams that want monitoring, status communication and on-call paging together, and would rather run or pay for one system than five. Unlike the lighter uptime tools in this category, it includes on-call schedules with phone and SMS escalation.