One Reliability Number Across Every Portfolio Company

Negotiating one enterprise contract across several portfolio companies, rather than letting each one keep its own separate subscription, typically brings a better rate and a single vendor relationship to manage.

Before evaluating incident.io against PagerDuty on features, add up what the portfolio is currently paying across every company's separate incident tooling, since that number alone often justifies standardizing before the platform choice is even settled.

Two companies both reporting a severity one incident does not mean the same thing happened at each, unless their severity definitions were built the same way. Standardizing on one tool solves nothing if each portfolio company still defines its own severity levels independently.

Build one shared severity rubric first, then apply it consistently as each company migrates onto whichever platform you choose. Skipping this step is the most common reason a rollup's reliability reporting still looks inconsistent a year after everyone is nominally on the same tool.

Say your operating partner pulls last quarter's incident counts from five portfolio companies and finds one reported twelve incidents, another reported two, on infrastructure that is otherwise comparable in size and complexity. The gap is rarely real; it is usually that one company's team logs every minor blip as an incident while another only logs full outages.

A shared rubric applied consistently across all five, not just the same software license, is what actually makes that comparison meaningful to a sponsor reviewing the numbers.

A sponsor asking for quarterly reliability metrics across the portfolio should not require someone manually pulling numbers from five different tools or five different configurations of the same tool.

Whichever platform you standardize on, confirm it can produce a consistent, cross-company report without a person reconciling formats by hand every quarter, since that manual reconciliation is exactly the kind of overhead a standardization effort is supposed to remove.

incident.io and PagerDuty are both capable platforms; the more consequential decision is which one costs less, in engineering time and disruption, to migrate several existing setups onto.

A portfolio company already running a mature PagerDuty deployment may resist a switch to incident.io purely for its Slack workflow, and that resistance has real cost. Weigh the disruption of migrating an already-working setup against the value of a fully unified platform before assuming standardization means everyone moves to the same tool immediately.

A workable order of operations for standardizing across a portfolio looks like this:

1. Add up what the portfolio currently pays across every company's separate incident tooling to see the case for one shared contract.
2. Build one shared severity rubric, then apply it consistently as each company migrates onto the chosen platform.
3. Confirm the platform can produce a consistent cross-company report without someone reconciling formats by hand every quarter.
4. Involve the team at any company with a mature setup before announcing a move, and weigh the disruption against the benefit of consistency.
5. Migrate companies on a schedule that fits how disruptive the switch is for each one, starting with those that have no formal tooling.

As portfolio companies mature toward an exit, engineering spend itself becomes a diligence data point worth tracking consistently: R&D spend as a share of ARR runs at a median around 22% across private B2B SaaS companies, with smaller companies often spending a larger share of revenue on engineering than bigger ones¹.

Tracking incident volume and severity alongside that spending figure, using the same definitions everywhere, gives a sponsor a more useful diligence signal than either number alone would provide.

The most common way a portfolio-wide standardization effort quietly fails is skipping the negotiation with whichever portfolio company already has the most mature setup. If one company runs a well-configured PagerDuty deployment its engineering team actually trusts, and the operating partner announces a portfolio-wide move to incident.io without involving that team in the decision, the result is often quiet resistance: shadow processes, informal workarounds, and a reliability number that looks standardized on paper but is not actually being followed day to day.

Involve the engineering lead from your most mature portfolio company in the platform decision itself, not just in the rollout schedule. Their setup is usually the closest thing you have to a working reference for what good looks like across the rest of the portfolio, and treating their input as a data point rather than an obstacle tends to produce a standard the other companies actually adopt rather than merely comply with on paper.

The same logic applies in reverse for a company with no formal incident process at all: standardizing gives that company something it did not have before, so the resistance there is usually about unfamiliarity rather than losing something that already worked. Sequence the rollout accordingly, starting with the companies that have the least to lose and the most to gain, and save the hardest conversation, the one with your most mature team, for when you have a working reference implementation elsewhere in the portfolio to point to.