Open-source alternative to Grafana Cloud IRM

Open-source alternative to Grafana Cloud IRM: GoAlert or OneUptime

Grafana OnCall OSS was archived on March 24, 2026, and its README points users to Grafana Cloud IRM, which is billed per active user. For self-hosted on-call, GoAlert is the better fit when you need scheduling, automated escalations and notifications and nothing more. Choose OneUptime when status pages and incident management must sit in the same tool as on-call. Both run in your own infrastructure, so the on-call roster, escalation policies and incident history stay under your control. The main trade-off to weigh is the per-active-user model of Grafana Cloud IRM against the operating effort of running either tool yourself.

GoAlert is distributed as a single binary with Docker images published for each release, and its only hard requirement is PostgreSQL. The getting started guide recommends PostgreSQL 17 or newer for new installations and requires the pgcrypto extension. Set a data encryption key before first use, because GoAlert encrypts sensitive values such as API keys before they are written to the database, and every instance must use the same key. GoAlert accepts alerts from Grafana and Prometheus sources, among others, so your existing alert pipelines can page the same schedules. Confirm the current release with the project before you pin a version, since GoAlert's release history changes often.

Notifications need an external provider. Twilio is currently the only supported provider for GoAlert voice and SMS, so the per-message and per-minute charges for SMS and voice come from Twilio, not from the on-call tool. Ask your telephony team to model expected page volume, international destinations and sender registration requirements before you commit. OneUptime also sends SMS, phone call, push, email and Slack alerts, so confirm which of its notification channels you can use in your region and which need a third-party account. Email and Slack escalation steps avoid voice charges entirely, but they do not replace a voice page for a critical outage.

Which Grafana Cloud IRM capabilities GoAlert and OneUptime cover

This table maps the on-call and incident capabilities that teams use in Grafana Cloud IRM to GoAlert, OneUptime Community Edition and OneUptime Enterprise. Read each row as a coverage note: supplied facts show what each platform documents, and items marked to confirm need a check with the vendor or a proof of concept before you commit.

Capability	GoAlert	OneUptime Community and Enterprise
Alert routing from Grafana and Prometheus	Documented alert sources include Grafana and Prometheus, plus a generic API and email	Ingests telemetry through OpenTelemetry-based agents; confirm direct routing of Grafana and Prometheus alerts into on-call
Schedules and rotations	Services, rotations, schedules and calendar subscriptions are documented	On-call schedules are included; confirm rotation patterns and override handling
Escalation policies	Automated escalation policies are documented	Escalation policies are included; confirm multi-step and repeat behavior
SMS and voice notifications	Voice and SMS use Twilio only, the sole supported provider	SMS and phone call alerts are included; confirm which carriers and providers are supported
Push and email notifications	Not listed in the documented feature set; confirm before relying on it	Push, email and Slack alerts are included; confirm mobile app behavior
Slack and chat notifications	Slack channels can be an escalation policy step	Slack alerts are included; confirm Microsoft Teams support
Incident declaration and post-mortems	Not a documented focus; pair with a separate incident tool if needed	Covers declaring and assigning incidents, communication, resolution and post-mortems
Status pages	Not provided	Branded public and private status pages with incident history and subscriber notifications are in Community Edition
Single sign-on	GitHub OAuth and any OpenID Connect provider; Dex suggested for other identity systems	SAML and OIDC in Community Edition; SCIM provisioning is listed for Enterprise only
Audit logs and APIs	Confirm API coverage and audit log depth with the vendor	Audit logs are listed for Enterprise; confirm audit log depth in Community Edition

When GoAlert, OneUptime or staying on archived Grafana OnCall fits

Three options cover different needs: a dedicated paging tool, a single platform that also handles status pages and monitoring, and the archived Grafana OnCall OSS that should not anchor new work. Each card names the fit, the trade-off and what to verify in a proof of concept before committing to a rollout.

GoAlert for dedicated paging

GoAlert is a single binary with on-call schedules, escalation policies, rotations and notifications, licensed under Apache 2.0. Its only hard requirement is PostgreSQL, and the getting started guide recommends PostgreSQL 17 or newer with the pgcrypto extension. Teams that already run PostgreSQL and want a narrow, auditable paging system fit well here. The trade-off is that you assemble the rest yourself, including status pages and monitoring. In a proof of concept, confirm that Twilio meets your SMS and voice requirements, that the data encryption key is shared across all instances, and that Grafana and Prometheus alerts arrive as expected.

OneUptime for one integrated tool

OneUptime bundles on-call schedules and escalation policies with status pages, incident management, uptime and synthetic checks, and OpenTelemetry-based log ingestion. Its Community Edition is Apache 2.0, except the ee/ directory, which uses the OneUptime Enterprise License. It fits teams that want one platform for alerting and public communication. The trade-off is a broader footprint to operate than a paging-only tool. In a proof of concept, verify which features you need sit outside ee/, test SMS and phone escalation end to end, and confirm the Docker Compose or Helm deployment on your own infrastructure.

Archived Grafana OnCall OSS

Grafana OnCall OSS entered maintenance mode on March 11, 2025 and was archived on March 24, 2026, and its README points users to Grafana Cloud IRM. Keep existing deployments running only as a short-term bridge while you plan a move, and do not adopt it for new work. The trade-off is that an archived project receives no further fixes, so security exposure grows over time. In a current environment, list the integrations, schedules and escalation rules you depend on, then confirm that each one can be recreated in GoAlert or OneUptime before you switch.

How to route Grafana and Prometheus alerts into self-hosted on-call

Map each alert rule to a GoAlert service and escalation policy before you wire anything up. GoAlert lists Grafana and Prometheus among its alert sources and also accepts alerts from a generic API and email, so a Grafana contact point, a Prometheus Alertmanager receiver or a plain HTTP call can all land in the same service model. For each rule, decide two things: whether a person must be paged now, and whether the alert only needs to reach a shared channel. Page a person for alerts that need action within the on-call window, such as a customer-facing outage or a failed backup. Send the rest to a Slack channel, which GoAlert can use as an escalation policy step. Keep the rule-to-service map in version control so every routing change gets the same review as other configuration.

Treat the GoAlert data encryption key as a secret with a named owner. GoAlert recommends setting this key so that sensitive values such as API keys are encrypted before they are written to the database, and its getting started guide asks for the same key on every instance. Values encrypted under one key may not decrypt under another, so store the key in your secrets manager, inject it identically into each deployment and write down how it is rotated. In a Kubernetes cluster, run one instance in the default engine mode and start the remaining instances with the --api-only flag. Confirm this split and the database switchover steps against the GoAlert getting started guide with your platform team before rollout.

Test every route with a controlled alert before cutover. Fire a test from Grafana and from Prometheus for each rule, then confirm the right service receives it, the escalation reaches the expected person after the delay you configured and the Slack step posts to the right channel. Repeat the test on the phone and SMS path. GoAlert currently supports only Twilio for voice and SMS, so confirm your Twilio account, sender numbers and billing before go-live. Keep existing routes active until every test passes. If you are evaluating OneUptime instead, plan a different design: it ingests alerts through its own monitors, which cover websites, APIs, ports, SSL and DNS, and through OpenTelemetry-based agents, so Grafana and Prometheus rules would usually be rebuilt as OneUptime monitors rather than forwarded unchanged.

Which on-call path fits a small team, a multi-team platform or a regulated organization

A small team whose only alert sources are Grafana and Prometheus usually needs a narrow tool: schedules, escalations and phone or SMS paging. GoAlert fits this shape well because it has a dedicated scope, ships as a single binary and accepts Grafana and Prometheus alerts directly. The main work is standing up a PostgreSQL database with the pgcrypto extension, running one GoAlert instance, and wiring the alert sources.

Likely option: GoAlert, with Grafana and Prometheus as alert sources.
Setup burden: One binary or Docker image, one PostgreSQL database and a data encryption key set identically on every instance.
Identity path: GitHub OAuth or any OpenID Connect provider for login, with Dex suggested if your identity system is not supported directly.
Notification cost: Twilio is the only supported provider for SMS and voice, so budget for Twilio usage and confirm current rates with Twilio.
Confirm: Whether a single responder group is enough, and whether you need status pages, which GoAlert does not provide.

Before you commit, confirm that your Grafana and Prometheus alert payloads map cleanly to GoAlert services and that Twilio is acceptable for your phone numbers and regions.

How on-call runs alongside Grafana, Prometheus and the rest of the stack

Moving on-call to a self-hosted tool changes one link in a chain that also includes alert sources, identity, team chat and status communication. The cards below cover the parts that keep running, who owns each connection, and what to confirm in vendor documentation before cutover.

Grafana and Prometheus as alert sources

Grafana alert rules and Prometheus Alertmanager routes currently send pages to Grafana Cloud IRM. When on-call moves, the alert rules themselves stay where they are, but each notification route must point at the new tool. GoAlert lists Grafana and Prometheus among its alert sources, so confirm the exact integration type and token setup for your version. Assign one owner to repoint every route and to test each alert end to end. Duplicate notifications are the usual risk: if Grafana runs in high availability, the alerting section of its docs describes extra configuration needed to avoid sending the same alert twice.

Grafana authentication editions

Grafana's authentication docs list LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT for all editions. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your team relies on SAML or SCIM for Grafana access, that requirement does not move with on-call and needs its own decision. Check which login method your Grafana instance uses today and whether group membership drives dashboard or alert permissions, because the on-call tool will need its own user mapping.

Identity provider for the on-call tool

GoAlert supports GitHub OAuth and any OpenID Connect provider for login, and suggests Dex to bridge other identity systems. OneUptime Community Edition includes SAML and OIDC single sign-on, while SCIM provisioning sits in its Enterprise Edition. Decide whether your identity provider will feed the on-call tool directly or through a bridge, and who maintains that connection. Removing a departing engineer from the identity provider should also remove their access to on-call schedules, so confirm how deprovisioning reaches the new tool.

Slack channels for team notification

GoAlert can notify a Slack channel as an escalation policy step, which keeps the team informed while a responder is paged. Slack does not replace the paging path: confirm that the escalation step reaches a person who can act, and that the Slack integration has a named owner who rotates its credentials. Check whether your current setup posts incidents to channels through Grafana Cloud IRM integrations, because those posts will stop when that service is turned off and must be recreated.

SMS and voice provider

GoAlert's getting started guide states that Twilio is currently the only supported provider for voice and SMS notifications. Calls and texts are billed by your provider, so the notification cost moves from the on-call vendor to an account you hold. Who opens and pays that account, and how the API keys are stored, are decisions to record before cutover. GoAlert recommends a data encryption key so that sensitive values such as API keys are encrypted before being written to the database, and the same key must be used on every instance.

Separate status page

If your organization runs a status page apart from on-call, that page keeps working but its incident feed may depend on the on-call tool. OneUptime Community Edition includes branded public and private status pages with incident history, scheduled maintenance and subscriber notifications, which can cover both incident declaration and customer communication in one place. Whether to consolidate is a planning decision. Confirm which status page tool is currently fed by Grafana Cloud IRM and who updates it during an incident.

What SMS and voice notifications add to self-hosted on-call costs

The software license is not where SMS and voice costs come from. GoAlert is licensed under Apache 2.0, and OneUptime Community Edition is Apache 2.0 except for its ee/ directory, so neither product charges a license fee for the notification engine itself. Every SMS and voice call still leaves the platform through a carrier, and Twilio is currently the only supported provider for GoAlert voice and SMS. Your Twilio account, the phone numbers you rent, and per-message (SMS) and per-minute (voice) usage are separate line items, and each rate varies by destination country. Request current Twilio rates for every country where your responders are located, along with number rental fees, and do not build the budget on older published figures.

Several smaller components recur alongside the carrier bill. GoAlert can notify Slack channels as an escalation step and can create alerts from email through Mailgun or its built-in SMTP ingress, so confirm the plan or message charges for Slack, Mailgun or your mail relay. The server, the PostgreSQL database that GoAlert requires, backups, and the time your team spends on upgrades all carry hosting costs. Usage drivers include the number of on-call users, how deep each escalation policy goes, how often a page is retried, and how many countries are involved. Ask for a written forecast of expected SMS and voice volume per country, because that forecast is what turns Twilio's rate card into a monthly figure. The GoAlert getting started guide explains the database and encryption key setup that belongs in the same scope.

Grafana Cloud IRM is billed per active user, so its cost follows the number of people in the on-call rota rather than the notification volume your team sends. Ask Grafana for a current IRM quote that states who counts as an active user, which notification channels are included and whether SMS or voice are billed on top. Then write a self-hosted scope that lists the Twilio rates for your countries, hosting and database, backups, Slack or email charges, and the staff time for setup and upgrades. Compare both totals over the same period and the same headcount. If you want the self-hosted scope fixed and in writing before you decide, DeployOpen can produce that scope as part of a quote.

How to move on-call schedules and escalations off Grafana Cloud IRM

This sequence moves on-call schedules, escalation policies and alert routing from Grafana Cloud IRM to a self-hosted tool, with a parallel run and a controlled drill before IRM access is retired.

Inventory IRM integrations, users and schedules
Your team lead for on-call and an administrator of IRM list every integration, user, schedule, rotation, escalation chain and alert rule that routes into IRM. Confirm first what IRM can export, because export options for schedules and escalation policies may be limited and some configuration may need to be rebuilt by hand. Keep the inventory in a version-controlled file so you can check each item off later. Done when every escalation chain has a named owner and every integration has a documented source, such as a Grafana alert contact point or a Prometheus Alertmanager receiver.
Deploy GoAlert in a test environment
Your platform engineers deploy GoAlert, which is distributed as a single binary and published as a Docker image, in a non-production environment. The only hard requirement is PostgreSQL, and the getting started guide recommends PostgreSQL 17 or newer for new installations, with the pgcrypto extension enabled. Set a data encryption key that is identical on every instance, because it protects API keys and other sensitive values stored in the database. Configure login through GitHub OAuth or an OpenID Connect provider, using Dex if your identity system is not supported directly. Done when a test user can sign in and the instance responds on its health check.
Rebuild services, rotations and escalation policies
Recreate each service, escalation policy, rotation and schedule from the inventory in GoAlert, and add calendar subscriptions where responders use them. Map each Grafana or Prometheus alert source to the matching GoAlert service so that incidents land in the right escalation chain. Connect Twilio for SMS and voice, since the getting started guide names it as the only supported provider for these notifications, and place a test call and text to every responder in the test environment. Done when each responder has received a test SMS and a test voice call, and the schedule shows the expected person for the coming weeks.
Route a copy of alerts in parallel
Add GoAlert as a second receiver for Grafana alert rules and for the Prometheus Alertmanager, so that IRM keeps paging as usual while GoAlert receives the same alerts. Use the Grafana, Prometheus or generic API alert sources in GoAlert, and confirm that each alert appears once with the correct service and severity. Keep the parallel run long enough to see normal alert traffic, including quiet hours and at least one scheduled handover. Done when every alert type in the inventory has arrived in GoAlert with the expected routing, and any mismatch has been fixed and retested.
Confirm acknowledgments and escalations with a drill
Run a controlled drill in which a test alert fires, the primary responder does not acknowledge, and the escalation moves to the secondary and then to the final step. Confirm that acknowledgment, close and escalation actions work from SMS, voice and the web interface, and that Slack notifications post to the intended channel if you use that step. Record the time each notification arrived and whether each responder acted on it, then review gaps with the on-call team. Done when the drill log shows every escalation step fired as designed and the team agrees on any changes.
Cut over routes and retire IRM access
Remove IRM as a receiver from Grafana contact points and Alertmanager, leaving GoAlert as the only paging path, and keep the IRM export files for audit. Update runbooks and the on-call handbook so responders know where to acknowledge alerts and who administers GoAlert. Revoke IRM user access once the parallel period has ended without missed pages, and cancel the IRM subscription only after your procurement and records teams confirm retention requirements. Done when a fresh test alert reaches the on-call person through GoAlert alone and IRM no longer receives production alerts.

What self-hosted on-call costs, how long it takes and what your team must provide

What does self-hosted on-call cost, and what drives it up or down?

Self-hosted on-call has no per-user licence fee from the software itself, because GoAlert is Apache 2.0 and OneUptime Community Edition is Apache 2.0 outside its ee/ directory. The costs are the servers and PostgreSQL database, the Twilio account for SMS and voice, the people who install and maintain the system, and the effort to write and test escalation policies. Recurring costs are infrastructure, Twilio usage and staff time for upgrades. One-time costs are the initial build, integrations and training. Notification volume, the number of responders, and how many alert sources you connect move the Twilio bill up. Ask any implementation partner for a quote that lists each component separately, including who pays Twilio and who runs the database.

Can our own team migrate on-call without outside help?

A team can migrate on its own when the setup is small: a few services, simple weekly rotations, one or two escalation policies and a handful of Grafana or Prometheus alert sources. GoAlert ships as a single binary with Docker images, and its only hard requirement is PostgreSQL, so the install itself is modest. Larger setups need an owner who is skilled in PostgreSQL operations and, if you run GoAlert on Kubernetes, in Kubernetes. That person handles high availability with one default instance and the rest in API-only mode, the data encryption key shared across instances, and database switchover. Confirm internally who will own those tasks before you decide.

How long does a self-hosted on-call migration take?

The timeline depends on scope, the number of integrations, the number of teams and how many drill cycles you run before cutover. No supplied figure gives a standard duration, so treat any number you hear as a claim to verify. A simple single-team rotation moves faster than a multi-team setup with Grafana, Prometheus, email and Slack alert sources and SSO. Plan at least one full drill cycle with real paging tests, because escalation mistakes show up only when alerts reach people. Ask for a written timeline tied to the agreed scope and the number of drills.

What does the work need from our environment and staff?

Prepare these before work starts: a PostgreSQL database that meets GoAlert's recommended version (PostgreSQL 17 or newer for new installations, with the pgcrypto extension), a place to host the binary or containers, and an identity option for login. GoAlert supports GitHub OAuth and any OpenID Connect provider, with Dex suggested to bridge other systems. You also need a Twilio account, because Twilio is currently the only supported provider for GoAlert voice and SMS. Agree change windows for cutover, access to your Grafana and Prometheus alert configuration, and named people who approve escalation policies and schedules.

Should we choose GoAlert or OneUptime for self-hosted on-call?

Choose GoAlert if you want a focused on-call scheduler and escalation engine with minimal moving parts, and you already run monitoring and status pages elsewhere. Choose OneUptime if you want on-call alongside uptime monitoring, incident management and branded status pages in one platform. OneUptime's Community Edition includes on-call schedules and escalation policies with SMS, phone call, push, email and Slack, but it runs as a larger system with Docker Compose or a Helm chart. Its Enterprise Edition features, such as SCIM and audit logs, are priced through sales. Test both against a copy of your real escalation policies before deciding.

How do we ask for a fixed-scope quote for self-hosted on-call?

Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Send a written brief listing the teams, the services and schedules to migrate, each alert source (Grafana, Prometheus, email, Slack or a generic API), the identity provider, the notification channels and expected volume, and your hosting and database constraints. Ask for deliverables, acceptance tests such as drill results, documentation, and what is handed over. DeployOpen does not publish a price list, so the quote follows from that written scope. Ask separately for ongoing support, which is available as a retainer.

What happens to on-call after go-live, including upgrades and support?

Plan for recurring upgrades from day one. GoAlert publishes releases on its GitHub releases page, for example v0.35.0 on September 21, 2026, so review each release notes entry and test it in a staging instance before production. OneUptime publishes releases such as 14.0.70 on October 18, 2026. Both are open source, so your team or a support retainer must own patching, backups, database maintenance and drill tests. Ask any provider which versions they support, how fast they apply upstream security fixes and what the escalation path is when on-call fails during an incident.

How DeployOpen scopes and delivers an on-call replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so on-call can run next to your Grafana and Prometheus alerting without leaving your environment. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.

How we scope

Inventory every alert source that currently pages people, including Grafana, Prometheus and any ticketing or chat tools in the path.
Define teams, services, escalation policies and rotations, and confirm which notification channels each team needs.
Agree in writing which platform fits the scope, whether GoAlert, OneUptime or a combination, and what stays out of scope.

How we build

Deploy the chosen platform in your cloud account, data center or air-gapped network, with PostgreSQL and the required extensions configured.
Connect Grafana and Prometheus alert routes to the on-call service, then test firing, acknowledgement and escalation end to end.
Configure single sign-on, encryption of stored API keys and notification provider accounts, and then run security testing on the deployment.

How we hand over

Document schedules, escalation policies, alert routing and the upgrade and backup procedures your operations team will run.
Walk through a live test page with responders and record the results so the team can repeat the drill after handover.
Deliver configuration as code where the platform supports it, so changes to rotations and routing are reviewed like other infrastructure.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the original engagement.
Retainers can cover platform version upgrades, database maintenance and review of notification provider costs each quarter.
Ask for the support scope, response expectations and upgrade cadence in writing before you sign, since these vary by agreement.

Open-source alternative to Grafana Cloud IRM