Why Teams Are Leaving Per-User Pricing for Incident Alerting
Per-user pricing on an incident alerting tool creates a mismatch: the bill scales with headcount, but the value the tool delivers — paging the right person reliably during an incident — stays roughly the same regardless of team size. A team of twenty pays roughly twenty times what a team of one pays, without getting twenty times the value.
Why this specific pricing model creates a specific problem
Most SaaS per-seat pricing is tied to how much value a new seat adds. Another salesperson using a CRM directly drives revenue, so the cost scaling with headcount tracks reasonably well with the value delivered. Incident alerting doesn't work the same way. The value of the tool is the same regardless of team size: get the right person paged, reliably, during an incident. A team of twenty doesn't get twenty times the value from their paging tool that a team of one does. They get roughly the same core service, just distributed across more people who might be on the rotation.
Per-user pricing on top of that dynamic means the bill grows in proportion to team size. It doesn't grow in proportion to how much the tool is actually being used, or how much value it's providing. That's a pricing model optimized for the vendor's revenue growth as a customer's team grows, not one that reflects the customer's actual usage.
How much more do you actually pay as the team grows?
More than the headcount increase alone suggests, once you account for how on-call rotations actually grow. Suppose a tool charges $20 per user per month and a team starts with five engineers on the rotation — that's $100 a month, easy to approve without much scrutiny. Now grow the team to fifteen, a completely ordinary size for a company that's scaled past its first few years. The same per-seat rate is now $300 a month, a 3x increase driven entirely by headcount rather than by any change in incident volume or tool usage. Add a second product team that also needs on-call coverage, and the number keeps climbing in a straight line with people added — whether or not those people are actually paging each other more often.
None of that growth reflects more value delivered by the tool. It reflects more people who could theoretically be on a rotation, which is a very different thing from more usage.
The moment teams usually notice
It's rarely the pricing page itself that triggers the switch. It's the specific moment of adding a new engineer to the rotation and watching the monthly bill jump by a per-seat amount that feels disconnected from what actually changed. Nothing about the incident volume changed. Nothing about the tool's usage changed. One more person is now eligible to be paged, and the bill went up as if that alone were the thing being purchased.
That moment tends to trigger a genuine cost comparison, often for the first time since the tool was originally chosen. Usually that's back when the team was small enough that the pricing model's long-term shape wasn't yet visible.
What teams look for instead
The alternative that keeps coming up is pricing tied to something that doesn't scale automatically with headcount — closer to what Stripe describes in its own docs on usage-based billing than to a per-seat model. That's a flat rate per pager slot — which can be shared or reassigned within a rotation, rather than locked to one named user — or a genuinely generous free tier that doesn't degrade as the team grows past some threshold.
This is a deliberate design choice, not an accident of a smaller vendor's pricing page. PingParrot charges per pager, not per user, with three pagers free forever and no feature gating on the free tier. Escalation policies, the REST API, and webhooks are all included from the start. A pager can be reassigned as team membership changes, so growing the team doesn't automatically grow the bill. It only grows if the team also needs more concurrent on-call slots, which is a genuinely different thing than headcount.
Concretely, that means a team can rotate a pager between people as its roster changes. Someone leaves, someone new joins the on-call pool, and the pager gets reassigned rather than requiring a new seat to be purchased and an old one canceled. The unit being paid for is a concurrent on-call slot, not a named individual. A team growing from eight engineers to twenty doesn't see its bill triple, unless it's also running more simultaneous rotations than it was before.
The real question to ask when evaluating pricing
Not "what does this cost today," but "what does this cost if the team doubles." Per-user pricing models answer that question in a way that should make anyone budgeting for growth pause. The bill doubles too, regardless of whether the actual on-call workload doubled with it. That's the comparison worth running before committing to a tool, not after the bill has already grown past the point of being easy to ignore.