Oncall

Last reviewed Sep 13, 2026 · 818 words

Oncall does not page anyone. That is the trap people walk into after reading "alternative to PagerDuty" on a directory page: LinkedIn's Oncall is the scheduling half of the problem, a calendar that knows who is on duty for which team at 03:00, exposed over a REST API. The half that phones, texts, or pushes to a mobile app is a separate LinkedIn project called Iris, and you will run both or you will have a very tidy rota that nobody ever hears from. Budget a weekend for the pair, not an evening for one.

What Oncall is actually good at

The scheduling model is the reason to bother. You define teams, add users with contact details and time zones, then build rosters with rotation rules: weekly primary, daily secondary, follow-the-sun across two offices, whatever the pattern is. Oncall fills the calendar forward from those rules, and engineers can swap shifts, request overrides for a dentist appointment, or subscribe to an iCal feed of their own duty. Every team gets a clean API endpoint like /api/v0/teams/{team}/oncall/primary that returns the current human, which is the thing your alerting pipeline actually needs. It has been running LinkedIn's rotations since 2017, and the 1,257 GitHub stars undersell how many mid-size SRE teams quietly use it.

Iris is not optional

Iris is LinkedIn's escalation and notification engine: plans, incident tracking, delivery over email, SMS, voice, and Slack, plus the mobile-app acknowledgement flow. Oncall answers "who", Iris does "how loudly and how many times". Both are Python services backed by MySQL, both ship a docker-compose file in their repositories, and the Oncall container is configured to point at an Iris instance for the "page this team now" button in its UI. If your source of alerts is Prometheus, you can skip Iris entirely and have Alertmanager call Oncall's API through a small webhook receiver to look up the person of the hour, then route to whatever channel you already have. That is how I would use it in a homelab or a team of 5.

The setup, and where it bites

The compose file in the repo brings up Oncall on port 8080 with a MySQL container and seeds the schema. Three things went wrong for me the first time. The database schema is loaded by a script rather than migrations, so upgrading across versions means reading the changelog and applying SQL by hand. Authentication defaults to a debug mode that trusts any login; switch it to LDAP or the built-in password module in config.yaml before anything faces a network. And the notifier that sends "you are on call tomorrow" reminders needs working SMTP or an Iris endpoint, or it silently drops them. With 256 MB RAM as the floor, the whole stack idles comfortably on a small VM alongside Uptime Kuma for the actual checks.

The UI is from 2017 and so is the pace

The interface is functional, dense, and looks its age: calendar grid, team page, a modal for overrides. Nothing is broken, but there is no dark mode, the mobile layout is an afterthought, and commit activity on the repository comes in bursts when LinkedIn needs something rather than on a release cadence. Treat it as stable infrastructure that will not change under you, which is a compliment for a rota tool, and not as a project with a roadmap.

Who should pick something else

Grafana wound down the open-source edition of Grafana OnCall, which was the obvious bigger sibling with scheduling and paging in one box, so the field is thinner than it was. For a solo operator or a household, Oncall is overkill: a single Alertmanager receiver to your phone covers it, and the monitoring category has the pieces. For a business that must prove escalation happened, PagerDuty or Opsgenie remain the safer choice; the PagerDuty alternatives page is honest about the gap. Oncall wins in exactly one band: a team of 5 to 50 engineers who already run Prometheus, want rotations in their own database, and have one person willing to own MySQL and LDAP.

What I'd do

Deploy Oncall from its compose file on the same VM as Prometheus and Alertmanager, wire LDAP for users, and write a 40-line webhook receiver that asks Oncall's API who is primary and forwards the alert to that person's Telegram or SMS gateway. Skip Iris unless you need voice calls and acknowledgement tracking, at which point install it too and accept a second MySQL schema to care for. Export the rotation to iCal so people see duty in their normal calendars, and nightly mysqldump both databases. It is not glamorous software, but a rota that has outlived several commercial competitors is worth 256 MB of RAM.