Open-source PagerDuty alternatives

Keep is an open-source platform for managing alerts and incidents. Teams that run several monitoring tools can bring their alerts into a single view, which saves them from jumping between dashboards, and then clean up the noise through deduplication, filtering, correlation and enrichment.

The platform connects to a long list of monitoring and observability products, and its integrations work in both directions so that data can be synced back to those tools. Workflows act like GitHub Actions for monitoring, letting you automate responses to alerts. AI features can correlate alerts and summarize incidents, using backends such as Anthropic, OpenAI, DeepSeek, Gemini, Grok or local models served by Ollama and LlamaCPP.

Keep is written in Python and the repository lists its license as Other. It positions itself as a customizable alternative to hand-built alert pipelines, with dashboards, documentation, a hosted demo and a request process for new providers. It suits SRE and DevOps teams dealing with alert fatigue across tools.

OneUptime is an open-source monitoring and observability platform that aims to replace a shelf of separate SaaS tools. It covers uptime monitoring, status pages, on-call and alerting, incident management, logs, traces, metrics, APM and error tracking in one application, and adds AI-assisted features such as helping find the root cause and proposing a fix.

Its README maps each module to the tools it can replace: Pingdom and UptimeRobot for uptime checks across websites, APIs, ports, SSL and DNS, StatusPage.io for branded public and private status pages, PagerDuty and Opsgenie for schedules, escalation policies and SMS, call, push or Slack alerts, Incident.io for declaring and triaging incidents with post-mortems, Datadog and New Relic for traces and dashboards, Loggly for logs, and Sentry for exceptions.

The Community Edition is open source under Apache 2.0 and free to self-host, and OneUptime Cloud offers a free-forever plan with no credit card. It is written in TypeScript. It suits small and mid-sized engineering teams that want one platform for reliability work rather than integrating many vendors.

Alerta is an alert aggregation and monitoring system. Its design goals are to be distributed and decoupled so it scales, to need minimal configuration while accepting alerts from any source, and to give a quick visual overview with the option to drill down into detail.

The server is a Python application that needs MongoDB or PostgreSQL as its only mandatory dependency; release 9 requires Python 3.9 or newer, PostgreSQL 13 or better, or MongoDB 6.0 or better. You install the server and command-line client with pip and start it with alertad, then add the web console from a release archive. Settings are overridden in a config file or through an environment variable, and Docker images are provided in a separate repository.

Alerta exposes an API server, which is how monitoring tools feed alerts in and how the web console and client read them. The project has been developed since 2012 and is licensed under Apache-2.0.

Oncall is a calendar application built by LinkedIn specifically for scheduling and managing on-call rotations. It is aimed at operations and engineering teams who need to track who is responsible for responding to incidents at any given time, and it is designed to act as a source of dynamic ownership information for paging systems such as Iris.

As a calendar-focused tool, its core job is representing on-call schedules in a way that other systems can query programmatically, rather than functioning as a full incident-management platform on its own. It integrates into a broader on-call and alerting workflow where a paging tool consults Oncall's schedule data to determine who to notify.

Oncall is written in Python and requires a MySQL database, with setup instructions covering local development, Docker Compose deployment, and configuration through a YAML file; dummy data can be imported for testing. It is released under the BSD-2-Clause license, and the README notes some current limitations, including no built-in test-running mechanism documented and a need to rebuild to apply code changes in some setups.