Runspace vs PagerDuty Runbook Automation

PagerDuty Runbook Automation is a mature, job-based automation platform built on open-source Rundeck. It suits teams that want scheduled and on-demand workflows run across their infrastructure. Runspace is a notebook-style runbook workspace for SRE and platform teams. Steps run inline, and a separate reviewer approves each run, pinned to the exact command and runbook revision. Runspace is in private pilots.

At a glance

The PagerDuty column comes from PagerDuty and Rundeck documentation, researched 2026-10-07. “Not found” means we didn’t find it in public docs. It doesn’t prove the feature is missing.

	PagerDuty Runbook Automation	Runspace
Execution model	Jobs and workflows built from existing scripts and tools. They’re triggered from the web UI, API, CLI or a schedule, and run against nodes over SSH or WinRM by default. The SaaS edition uses Runbook Runners, agents in your network that pull pending steps and send back encrypted results.	Executable runbooks. Each step runs inline and its output streams underneath, like a notebook. Variables can hold values captured from an earlier step’s output.
Approvals	Marketing describes “approval workflows” and role- and context-based permissions so that “only approved automations are available”. That gates which jobs can be run. We found no documented per-run reviewer gate.	Each run is approved by a separate reviewer, and the approval is tied to the exact command and runbook revision.
Audit	An audit trail of logins, views, job create, run, update and delete, and ACL changes. A commercial Audit Stream Plugin sends events to Datadog, New Relic, Splunk or webhooks. The SaaS edition has a job activity log.	A server-side audit log of who ran what, where, and who approved it.
Access control	YAML ACL policies covering projects, jobs, nodes and other resources, assigned to groups. The GUI ACL builder is commercial.	Roles and restricted runbooks control who can edit, run and approve.
SSO	OIDC/OAuth2 SSO is a commercial feature. Open source supports LDAP/AD, PAM, pre-authenticated headers and container auth.	Sign-in through your identity provider. Supported protocols aren’t documented yet.
Change review / versioning	A Git SCM plugin exports and imports job definitions, so review happens in pull requests outside the product. We found no built-in review step before publishing.	Changes are reviewed and approved before they publish, and approvers see only what differs. Published revisions can’t be changed.
AI / agent help	The Rundeck MCP Server went GA on 2026-10-07, for Rundeck and self-hosted Runbook Automation 6.1.0+. It builds, imports and runs jobs under the user’s API token and asks for human confirmation on destructive actions. The SaaS edition can generate a starting job from a prompt.	Your agent (Claude Code or Codex) suggests the next command, and nothing runs without approval. Terminal capture turns shell history or an incident session into a runbook draft.
Deployment	SaaS (Runbook Automation), Self-Hosted, or open-source Rundeck.	Not yet documented (private pilots).
License	Commercial. The Rundeck core is Apache 2.0.	Commercial. License terms aren’t published.
Pricing	SaaS lists at $125 per user per month plus a platform fee, with a 14-day trial. Self-Hosted is “Call Us”.	Solo is $20/month. Multiplayer is $40 per user per month ($34 billed annually) with a 2-seat minimum. Pricing isn’t final.

Where PagerDuty Runbook Automation is stronger

Maturity. The Rundeck line has been in production use for over a decade. Recent releases have reached 6.2.1, and the SaaS edition comes with a 99.9% SLA. Runspace is in private pilots, has no published SLA, and has no customers it can name.

Integrations. PagerDuty lists integrations with ServiceNow, Kubernetes, Ansible, Datadog, VMware and GitHub, plus advanced webhooks and a large plugin ecosystem. It’s sold as part of PagerDuty’s Operations Cloud with a tie-in to incident management. For integrations beyond agent help, Runspace currently has only Claude Code and Codex.

Scheduling and job control. Scheduling, blackout calendars, job queuing, resuming failed jobs and retrying failed nodes are all documented. Commercial editions add clustering and high availability. These suit repeatable automation that runs unattended. Runspace hasn’t documented equivalents.

Self-hosting and private networks. You can run the commercial product yourself (Self-Hosted), use the SaaS edition with Runbook Runners inside your network, or run open-source Rundeck. Runspace hasn’t published deployment options.

Open source. Rundeck is Apache 2.0 and free, which is a real advantage for teams that want to start without procurement or inspect the code.

Agent tooling today. The Rundeck MCP Server is generally available and gives agents real write access to jobs and ACL policies.

Where Runspace differs

Per-run approval by a separate reviewer. In Rundeck, ACLs decide who may run a job. Once someone has permission, they run it. We found no documented step where a second person approves a specific run. The MCP server’s confirmation for destructive actions is given by the same user. Community posts describe chaining jobs and notifications to simulate a “wait for approval” step. In Runspace, a separate reviewer approves each run, and the approval is pinned to the exact command and runbook revision.

Review inside the product. In Rundeck, review happens in Git: you export job definitions, review them as pull requests and import them back. PagerDuty’s own deployment guide recommends this. It works for many teams. Runspace builds the review into the product instead: changes are approved before publishing, approvers see only the diff, and published revisions can’t change.

Notebook-style runbooks, not jobs. Runspace is for runbooks people work through by hand: instructions, checklists and commands together, with output streaming under each step. Rundeck turns procedures into jobs. That’s a better fit when the work should be automated, and a worse one when an engineer needs to read, decide and run step by step.

From incident to runbook. Runspace’s terminal capture turns an incident’s terminal session or shell history into a runbook draft, which the team then reviews. We found no equivalent in PagerDuty’s documentation.

A more conservative agent default. Agents connected to the Rundeck MCP server can run jobs with the user’s token and need confirmation only for destructive actions. In Runspace, the agent suggests commands and nothing runs without approval.

Price. Runspace’s current Multiplayer price is $40 per user per month, compared with a $125 list price plus platform fee for PagerDuty’s SaaS edition. Runspace’s pricing isn’t final, and the two products cover different scope.

Which should you choose?

• You need scheduled, unattended automation across many nodes, with HA and an SLA: choose PagerDuty Runbook Automation.
• You already run PagerDuty and want automation tied to incident response, or you need ServiceNow, Ansible or Kubernetes plugins today: choose PagerDuty Runbook Automation.
• You need self-hosting or a free open-source start: use Rundeck open source or Runbook Automation Self-Hosted.
• Your runbooks live in wikis and get run by copy-paste, and you want them executable with a record of every run: Runspace is designed for this.
• Your risk or compliance process needs a second person to approve a specific command before it runs, and an audit record that shows it: Runspace’s approval model is built around this. With Rundeck you’d have to assemble it yourself.
• You want incident terminal work to become reviewed runbooks: look at Runspace.

The two can also run side by side: Rundeck for scheduled jobs, Runspace for hands-on procedures that need approval. Runspace is in private pilots. If you request a pilot, we’ll reach out to set one up with your team.