{"slug": "open-oncall-open-source-alternative-to-devin-oncall", "title": "Open Oncall: Open-Source Alternative to Devin Oncall", "summary": "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.", "body_md": "# Open Oncall\n\nAn 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.\n\n**Sleep better without relying on a single provider.**\n\nOpen 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.\n\n## [What you import](#what-you-import)\n\nEvery file lives next to this page on the docs site. Download it, fill the placeholders, import it.\n\n| File | What it is | \n|---|---|\n| [`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 | \n| [`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` | \n| [`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` | \n| [`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 | \n| [`open-oncall.app.json`](https://docs.agent-swarm.dev/playbooks/open-oncall/open-oncall.app.json) | The Open Oncall app definition | \n| [`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 | \n\n## [Prerequisites](#prerequisites)\n\n- **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.\n- **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.\n- **A repo** the workers can clone and open PRs on, with the[GitHub integration](https://docs.agent-swarm.dev/docs/integrations/github) set up.\n- **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.\n\n## [Install](#install)\n\nRun these as your Lead. The Lead must create the workflow: its Slack posts go through `slack-post`, which only a lead may call.\n\n**1. The script and the webhook secret.**\n\n**2. The failover block.**\n\n**3. The workflow.** Fill your channel, repo, PagerDuty service name and approver. `GET /api/users` lists user ids.\n\n`SERVICE_REPOS` takes several pairs (`svc-a=org/a,svc-b=org/b`). Only repos in `ALLOWED_REPOS` are ever touched.\n\n**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.\n\n**5. Fire a test alert.**\n\nThe 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?}`.\n\n## [The Slack approval flow](#the-slack-approval-flow)\n\nThe 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.\n\n- **Approve** : the fix step opens one PR on the repo. Nothing is merged.\n- **Reject** , or no answer within 6 hours: the incident is handed to a human.\n- Only people listed in `approvers` can answer. Agents get a 403.\n\nThe last message in the thread is the outcome: the PR, time to root cause, time to PR, and which provider handled each step.\n\nAlerts 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.\n\n## [Provider failover](#provider-failover)\n\nThe engine's node `retry` re-runs the same agent, so the reroute lives in the workflow:\n\n1. `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.\n2. The failover block runs the step on the first worker. A failed attempt turns into a `[FAILED: reason]` output instead of failing the run.\n3. A `property-match` sees`[FAILED:` and sends the same prompt to the worker on the next harness, up to three attempts.\n4. `pick` returns the first success and one provider record per attempt: harness, agent, model, status, reason, and whether it looked like a provider error.\n5. `close` writes those records to the run output (`providers.investigate` ,`providers.fix` ) and to the last Slack message.\n\n### [Drill it with `simulateProviderDown`](#drill-it-with-simulateproviderdown)\n\n`simulateProviderDown`\nAdd `simulateProviderDown` to any trigger. The attempt on that harness fails on purpose, as a real task, and the step moves to the next provider.\n\nThe thread marks the run as a drill, and the outcome names the reroute: `investigate → codex, failed over from claude simulated outage`.\n\n## [The app](#the-app)\n\nThe Open Oncall app reads the workflow's runs and shows:\n\n- **Incidents** : status (investigating, awaiting approval, fixing, resolved, handed to a human), severity, failover, time to root cause and age.\n- **Pending approvals** : Approve and Reject answer the same request the Slack thread links to, so one answer resolves both.\n- **Incident detail** : the timeline from alert to resolution, with the provider, agent and model of every step. Failed attempts show as`FAILOVER` .\n\nTo 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:\n\nThe 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.\n\n## [Limits](#limits)\n\n- **Approval is a link, not Slack buttons.** \"Review & respond\" opens the dashboard; the app's Approve and Reject buttons answer the same request.\n- **PagerDuty signatures.** The trigger checks the`X-Open-Oncall-Token` header, not PagerDuty's`X-PagerDuty-Signature` .\n- **Failover fires on any failed attempt** , not only provider errors. Each provider record says which kind it was.\n- **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.\n- **Every human message in an alert channel starts a run** that stops at`gate` . Filter runs on`intake.result.accept = true` .\n\nEmail Domain Health\n\nA 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.\n\nHot Patterns\n\nFive 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.", "url": "https://wpnews.pro/news/open-oncall-open-source-alternative-to-devin-oncall", "canonical_source": "https://docs.agent-swarm.dev/docs/playbooks/open-oncall", "published_at": "2026-10-16 10:45:03+00:00", "updated_at": "2026-10-16 11:10:43.134094+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-infrastructure"], "entities": ["Open Oncall", "Agent Swarm", "PagerDuty", "Slack", "GitHub", "Claude", "Codex", "OpenCode"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/open-oncall-open-source-alternative-to-devin-oncall", "markdown": "https://wpnews.pro/news/open-oncall-open-source-alternative-to-devin-oncall.md", "text": "https://wpnews.pro/news/open-oncall-open-source-alternative-to-devin-oncall.txt", "jsonld": "https://wpnews.pro/news/open-oncall-open-source-alternative-to-devin-oncall.jsonld"}}