Runbook automation that is not a bolt-on, or a per-seat bill.
Rundeck did runbook automation before most people had a word for it, and PagerDuty's incident integration is genuinely good. The difference is what you pay as the team grows, and whether the product is somebody's main business.
Claims about other products verified . Each one is sourced on this page.
Per user is the part that compounds.
~$15K
per year, plus platform fee
Flat
per organisation, quoted against the team
$0
up to the tier's user limit
Per-seat pricing quietly discourages the thing automation is supposed to enable: giving more of the team safe access to the runbooks. Flat pricing does not make you choose between the budget and the access model.
What each one costs before it runs a command.
Rundeck's own system requirements, against ours. The figures on the left are quoted from their documentation, not estimated by us.
- 1Java 17 or later (supported through Java 25)
- 2A production database: MariaDB, MySQL, PostgreSQL, SQL Server or Oracle
- 38GB RAM and 2 CPUs minimum per instance, 32GB and 8 CPUs recommended
- 4A server to run it on, with ports 4440 and 4443 exposed
- 5Patch and upgrade the JVM, the database and Rundeck itself from then on
Their docs warn against the embedded H2 database in production, so the database is not optional at any real size.
Rundeck system requirements- 1Sign in
- 2Add one line to authorized_keys on a host
- 3Run something
No JVM, no database, no server of ours. Nothing runs on your hosts either.
| Capability | Opafra | PD Runbook Automation |
|---|---|---|
| Pricing model | Per organisation, by user band | Per user, plus a platform fee |
| 10-person team, per year | Per organisation, by user band | About $15,000 plus platform fee |
| Cost of adding the 11th person | $0 up to the tier limit | Another seat |
| AI plan composer | Yes | No |
| Access control | Per-environment grants, in the UI | ACL policy files |
| Time-limited access grants | Yes | No |
| Run-to-run diff | Yes | No |
| Environment derived from the targets | Yes | No |
| Hosted option | Yes | Yes |
| Self-hosted option | On request | Yes |
| Contractual SLA | Enterprise plan | Yes |
| Plugin catalogue | Modules, smaller | Years of plugins |
Sources: PagerDuty pricing · Rundeck documentation · Last verified September 2026
Runbook automation is a feature of somebody's incident product now.
PagerDuty acquired Rundeck in 2020, and the product that came out of it is sold as part of an incident-response platform. That is not a criticism. If your team lives in PagerDuty and the thing you want is to attach a runbook to an incident so a responder can press it at 3am, the integration is the whole point and it works.
It does change what you should expect from the roadmap. Runbook Automation earns its investment by making incident response better, so the features that get attention are the ones on that path. Scheduled maintenance across a fleet, change approval for planned work, and a record an auditor will accept are adjacent concerns rather than the main one.
Rundeck Community is still there and still free, and for a team that wants a job runner with a web UI it remains a reasonable answer. What sits in the commercial bundles is the part that matters at scale: high availability, clustering and the advanced ACLs. That is a normal open-core split and worth knowing before you plan around the community edition.
What $125 per user per month implies about who it is for.
Hosted Runbook Automation lists at $125 per user per month plus a platform fee. Self-hosted is quote-only. Those are their published numbers and they tell you who the product is designed for: a small group of specialists operating runbooks on behalf of everyone else.
That model works until the people who should be running the change are not the people holding seats. Then you get the pattern every operations team recognises: a queue in front of the two engineers with access, and a set of changes that go around the tool entirely because waiting was worse.
We price per organisation by user band rather than per seat, which is a deliberate bet that more of your team should be able to run a governed change, not fewer. An approval gate is a better control than a licence you cannot afford to hand out. If your team is genuinely five specialists and will stay that way, the per-seat price may work out fine and the arithmetic is worth doing honestly.
When PagerDuty Runbook Automation is the right choice
- You live in PagerDuty incidents end to end. Triggering automation directly from an incident, with the same on-call graph, is real gravity and we do not match it.
- You need a SOC 2 report in the procurement pack. Theirs is in place.
- You depend on specific long-standing plugins. Their catalogue has years on ours.
- You require a self-hosted deployment as a standard option. We offer a customer-hosted execution model on request, not as an off-the-shelf install.
- PagerDuty Runbook Automation lists at $125 per user per month plus a platform fee for the hosted product; the self-hosted variant, Process Software, is quote-only. PagerDuty automation pricing
- High availability, clustering and advanced ACLs sit in the enterprise bundles rather than the community edition. Rundeck documentation
Last verified September 2026