Open Oncall: Open-Source Alternative to Devin Oncall

Open Oncall launched as an open-source on-call workflow for Agent Swarm that ingests alerts from PagerDuty, Datadog, Grafana, Opsgenie, Sentry, SigNoz or any webhook, has an AI swarm investigate code, git history and telemetry, and opens a fix PR after a human approves in one click. The workflow ships as six importable files, including a 9-node main workflow with webhook and slack.message triggers, a failover sub-workflow, and a global script with intake, pick, findings and close ops. Failover re-runs a failed step across the Claude, Codex and OpenCode harnesses, requiring at least two online workers on different harnesses.

Open Oncall An alert lands in Slack, the swarm finds the root cause, a person approves the fix in one click, and the swarm opens the PR. If one AI provider is down, the step reroutes to another. One workflow, one failover sub-workflow, one script and an app, ready to import. Sleep better without relying on a single provider. Open Oncall is an open source on-call workflow for Agent Swarm. A PagerDuty incident fires or Datadog, Grafana, Opsgenie, Sentry, SigNoz, any webhook . The swarm opens a Slack thread, investigates the code, git history and telemetry, posts the root cause with a one-click approval link, and opens the fix PR once a person approves. If the provider running a step fails, the same step re-runs on the next harness: Claude, then Codex, then OpenCode. What you import what-you-import Every file lives next to this page on the docs site. Download it, fill the placeholders, import it. | File | What it is | |---|---| | open-oncall.workflow.json https://docs.agent-swarm.dev/playbooks/open-oncall/open-oncall.workflow.json | The main workflow: 9 nodes, webhook and slack.message triggers | | open-oncall-failover.workflow.json https://docs.agent-swarm.dev/playbooks/open-oncall/open-oncall-failover.workflow.json | The failover block, a sub-workflow used by investigate and fix | | open-oncall.script.ts https://docs.agent-swarm.dev/playbooks/open-oncall/open-oncall.script.ts | Global script open-oncall : ops intake , pick , findings , close | | open-oncall-app-sync.script.ts https://docs.agent-swarm.dev/playbooks/open-oncall/open-oncall-app-sync.script.ts | Script that projects workflow runs into the app | | open-oncall.app.json https://docs.agent-swarm.dev/playbooks/open-oncall/open-oncall.app.json | The Open Oncall app definition | | pagerduty-incident-triggered.sample.json https://docs.agent-swarm.dev/playbooks/open-oncall/pagerduty-incident-triggered.sample.json | A PagerDuty v3 incident.triggered payload to test with | Prerequisites prerequisites - Agent Swarm with a Lead and the Slack integration https://docs.agent-swarm.dev/docs/integrations/slack connected. The bot must be a member of your on-call channel. - Two or more providers. At least two online workers on different harnesses among claude , codex and opencode . One worker per harness is enough. Failover needs a second harness to fail over to. - A repo the workers can clone and open PRs on, with the GitHub integration https://docs.agent-swarm.dev/docs/integrations/github set up. - An alert source. PagerDuty v3 webhooks , or anything that can POST JSON: Alertmanager, Grafana, SigNoz, Datadog, Opsgenie, Sentry. To let investigators read traces and logs, connect your observability MCP for example SigNoz to the workers. Without it they work from code, git history and CI. Install install Run these as your Lead. The Lead must create the workflow: its Slack posts go through slack-post , which only a lead may call. 1. The script and the webhook secret. 2. The failover block. 3. The workflow. Fill your channel, repo, PagerDuty service name and approver. GET /api/users lists user ids. SERVICE REPOS takes several pairs svc-a=org/a,svc-b=org/b . Only repos in ALLOWED REPOS are ever touched. 4. Point PagerDuty at it. In PagerDuty, add a Generic Webhook v3 subscription for incident.triggered with the webhook URL above and a custom header X-Open-Oncall-Token set to $ONCALL TOKEN . Other event types stop at gate . Any other source uses the same URL and header. 5. Fire a test alert. The sample payload names the checkout-api service; the jq call swaps in yours. The intake script also accepts Alertmanager or Grafana status , alerts , Datadog title , body , alert transition , Opsgenie action: Create , Sentry data.issue or data.event and plain JSON {alertText, service?, repo?} . The Slack approval flow the-slack-approval-flow The bot posts the alert as the thread root, then "Investigating" with the planned provider chain. When the investigator finishes, it posts the root cause, the evidence, the proposed fix and a Review & respond link. One click opens the approval request in the dashboard. - Approve : the fix step opens one PR on the repo. Nothing is merged. - Reject , or no answer within 6 hours: the incident is handed to a human. - Only people listed in approvers can answer. Agents get a 403. The last message in the thread is the outcome: the PR, time to root cause, time to PR, and which provider handled each step. Alerts can also come from Slack itself: a human message in a channel listed in ALERT CHANNELS that matches ALERT PATTERN starts a run. Bot messages never do, so point alerting tools at the webhook instead. Provider failover provider-failover The engine's node retry re-runs the same agent, so the reroute lives in the workflow: 1. intake reads the live agent registry and plans a chain per step: one online worker per harness, in PROVIDER ORDER claude,codex,opencode , best capability match first. 2. The failover block runs the step on the first worker. A failed attempt turns into a FAILED: reason output instead of failing the run. 3. A property-match sees FAILED: and sends the same prompt to the worker on the next harness, up to three attempts. 4. pick returns the first success and one provider record per attempt: harness, agent, model, status, reason, and whether it looked like a provider error. 5. close writes those records to the run output providers.investigate , providers.fix and to the last Slack message. Drill it with simulateProviderDown drill-it-with-simulateproviderdown simulateProviderDown Add simulateProviderDown to any trigger. The attempt on that harness fails on purpose, as a real task, and the step moves to the next provider. The thread marks the run as a drill, and the outcome names the reroute: investigate → codex, failed over from claude simulated outage . The app the-app The Open Oncall app reads the workflow's runs and shows: - Incidents : status investigating, awaiting approval, fixing, resolved, handed to a human , severity, failover, time to root cause and age. - Pending approvals : Approve and Reject answer the same request the Slack thread links to, so one answer resolves both. - Incident detail : the timeline from alert to resolution, with the provider, agent and model of every step. Failed attempts show as FAILOVER . To install it, save the sync script, create the app with its id, and refresh it every 2 minutes with the seeded app-sync-run script: The app is built with the Apps https://docs.agent-swarm.dev/docs/apps feature. Ask your Lead to restyle it or add views with the apps skill. Limits limits - Approval is a link, not Slack buttons. "Review & respond" opens the dashboard; the app's Approve and Reject buttons answer the same request. - PagerDuty signatures. The trigger checks the X-Open-Oncall-Token header, not PagerDuty's X-PagerDuty-Signature . - Failover fires on any failed attempt , not only provider errors. Each provider record says which kind it was. - A fully offline harness does not fail its task. If a worker never claims the task, failover does not fire. There is no per-step timeout yet. - Every human message in an alert channel starts a run that stops at gate . Filter runs on intake.result.accept = true . Email Domain Health A daily monitor for the domains you send mail from. One saved script checks SPF, DKIM, DMARC, MX, provider records and blocklists on two DNS-over-HTTPS resolvers, sends one test email and captures its score, counts bounces, writes history to a Swarm App, and alerts only when something gets worse. Hot Patterns Five patterns that recur across every playbook — litmus tests, drain loops, HITL gates, per-customer working directories, and no-op workflows. These are the recipes that compound, regardless of which use case you're building.