Why Teams Are Leaving Per-User Pricing for Incident Alerting
Per-user pricing on an incident alerting tool looks completely reasonable at five people. The monthly bill is small, the per-seat rate seems fair, and it's easy to not think about it again. The math changes — often abruptly — once a team is adding its eighth, tenth, or twelfth engineer to the on-call rotation, and the same tool that felt cheap at launch is now a real line item that scales with headcount rather than with actual usage.
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, not 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.
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 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 — 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 unless the team also needs more concurrent on-call slots, which is a genuinely different thing than headcount.
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.