Usage-based pricing has arrived in the on-call market, and it is about to reshape how much your incident response tooling costs. PagerDuty is moving its customers away from the seat-based model that has defined the category for a decade and toward a usage-based model where you pay for what your platform actually does, not just how many people log in. Management has confirmed that more than fifteen customers spending over $100,000 a year have already transitioned, and analysts expect the broader enterprise base to follow. For engineering and DevOps leaders, this is not an abstract finance story. It changes how you budget for reliability, how you provision access to your incident tooling, and in some cases whether your team hesitates before paging. This post breaks down what the shift means, why it is happening now, the near-term disruption to watch for, and a practical playbook to keep your on-call spend predictable.
For most of the incident management category's history, pricing has been anchored to seats. You counted the responders who needed access, multiplied by a per-user monthly rate, and that was roughly your bill. The list rates people quote today still reflect that world, running from around $21 per user per month on the Professional tier up to roughly $41 per user per month on Business, with custom pricing above that. Seat-based pricing is simple to reason about and easy to forecast, which is exactly why it became the default.
Usage-based pricing rewires that logic. Instead of charging primarily for the number of humans with logins, the vendor charges based on what the platform processes: events ingested, alerts routed, automation actions executed, AI-assisted workflows run, and other measurable units of work. PagerDuty's own framing is that it wants to reduce reliance on seat-based pricing and drive higher annual recurring revenue by aligning cost with adoption of the wider Operations Cloud. In practical terms, the meter now runs on the machinery of your incident response, not just the roster of people watching it.
The distinction matters because seats and actions scale very differently. A team of eight engineers might handle a handful of pages on a quiet week and several hundred during a bad one. Under seat pricing, both weeks cost the same. Under usage pricing, the bad week can cost noticeably more, because every alert, every escalation hop, and every automated remediation step is a billable event. The unit of value shifts from "who has access" to "how much work the system did on your behalf." That is a more honest reflection of the value a platform delivers, but it also transfers volatility from the vendor's revenue line straight onto your monthly invoice.
There is a second, subtler effect. Usage-based models tend to bundle access to everything. PagerDuty has signaled that the usage-based Operations Cloud gives customers access to all platform products and deliberately incentivizes more cross-departmental use. That is attractive if you want one tool across many teams, but it also means consumption can grow in places you are not watching, because the friction of "do we buy another seat" no longer gates expansion.
The timing is not a coincidence. The single biggest force pushing vendors toward usage-based pricing is the rise of AI inside operations tooling. The logic is straightforward: when one human can trigger a dramatically larger number of actions through AI agents, the output from a single seat becomes far greater than it was when a person clicked through workflows by hand. Seat-based pricing quietly assumed a rough ceiling on how much value one login could generate. AI removes that ceiling. A single on-call engineer supervising AI agents that triage, correlate, and remediate can drive the work of what used to be a whole team.
From the vendor's perspective, continuing to charge per seat in an AI world means leaving money on the table as usage explodes while headcount stays flat. PagerDuty leadership has been explicit that AI adoption makes per-seat economics less profitable, which is why the company is repositioning around consumption. Expect competitors to feel the same gravitational pull. If the category leader proves that usage-based pricing captures AI-driven value better, incident.io, Opsgenie's successor products, Rootly, and others will face pressure to follow, at least for their AI-heavy features.
Whenever a large vendor changes its pricing model mid-stream, the transition is rarely smooth for existing customers. PagerDuty itself has acknowledged that only a small fraction of clients have adopted the new model so far, and that the migration is creating near-term disruption even as analysts view the long-term direction favorably. For the teams living inside that transition, "near-term disruption" translates into some very concrete problems.
The most immediate risk is renewal shock. Independent breakdowns of PagerDuty pricing have documented customers seeing large jumps at contract renewal, in some cases several times their prior spend, frequently attributed to increased API and usage charges layered on top of the base subscription. Annual contracts in this category commonly bake in price increases at renewal, so year-two costs can look meaningfully different from what a team signed up for in year one. When you add a shift toward consumption billing on top of that, the range of possible outcomes at renewal widens considerably. A team that instrumented more services, wired up more integrations, and leaned into automation over the year could find that all of that healthy adoption shows up as a much bigger number.
The uncomfortable part is that the behaviors usage pricing charges for are often the behaviors you were told to adopt. Connect every service to alerting. Automate your runbooks. Route intelligently. Under seat pricing, doing all of that was free once you had the seats. Under usage pricing, each of those good practices carries a marginal cost, and the bill arrives at renewal when your leverage to negotiate is lowest.
Usage-based pricing also makes forecasting harder, which is a real operational burden for the platform and SRE teams who own these budgets. Seat pricing gave finance a clean, predictable line item. Consumption pricing turns that line item into something that moves with incident volume, deployment frequency, and how aggressively teams adopt AI features. A quarter with a couple of major incidents, a noisy new integration, or a spike in automated actions can push spend well above plan.
That variability creates awkward incentives. Do you cap event ingestion and risk missing signal? Do you throttle automation to control cost, undercutting the very efficiency you bought the platform for? Teams that fail to instrument cost observability alongside their reliability observability can find themselves reacting to invoices the same way they react to outages, after the damage is already visible. The healthiest response is to treat cost as a first-class operational metric with its own dashboards and alerts, not as a quarterly surprise from procurement.
Beyond the budget, there is a cultural risk that deserves attention because it strikes at the heart of good on-call practice. When paging, escalating, and automating all cost money at the margin, some teams will consciously or unconsciously start to do less of them. That is a dangerous incentive to introduce into a reliability function.
The entire point of a mature on-call program is that the right person gets woken up at the right time with the right context, and that nobody hesitates to escalate when they are unsure. If every escalation hop and every notification is a metered event, you introduce a small but real disincentive to escalate. Multiply that across a large organization and you risk a slow drift toward under-paging, delayed escalations, and reluctance to instrument new services, all in the name of cost control. None of these will show up as a line in a postmortem, but they quietly raise your mean time to acknowledge and your mean time to resolve.
The lesson is not that usage-based pricing is inherently bad. Paying for value you actually consume is reasonable, and for low-volume teams it can even be cheaper than paying for seats they barely use. The lesson is that you have to design your pricing relationship so that it never makes engineers think twice about doing the right thing during an incident. The moment cost enters the escalation decision, reliability suffers.
Whether your team stays with a usage-based incumbent or evaluates alternatives, the response to this market shift should be deliberate rather than reactive. Here is a concrete set of moves to protect both your reliability and your budget as usage-based pricing spreads across the on-call category.
The through-line here is ownership. Teams that treat pricing as something that happens to them get renewal shock. Teams that treat consumption as one more system to observe and manage keep control of the outcome.
The pricing shift is a good moment to step back and ask what you actually need from on-call tooling, because complexity and cost tend to grow together. A large share of incident response coordination already happens where your engineers live, which for most teams is Slack. The paradox of the heavyweight incident platforms is that they pull people out of the place they are already working to acknowledge alerts, update statuses, and coordinate, and then they charge more as that activity scales.
Pagerly takes the opposite approach. It is a Slack-native on-call and incident management tool, which means schedules, escalation policies, alerting, and incident coordination live inside the tool your team already uses all day. Responders acknowledge and escalate without context switching, on-call handoffs happen in the channels where the work is already visible, and the people who need to be looped in are one message away rather than one more login away. For teams weighing the usage-based transition at a legacy vendor, a Slack-native model offers two things that matter right now: it keeps incident response fast because it removes the friction of jumping between tools, and it keeps cost far more predictable because the value does not depend on metering every event through a separate platform.
That predictability is the quiet advantage. When your on-call tooling has straightforward pricing, engineers never hesitate to page, escalate, or instrument a new service, because none of those actions carry a hidden marginal cost. You get the behavior good reliability requires without the budget anxiety usage-based models can introduce. If you are already comparing quotes as part of your renewal due diligence, a Slack-native option like Pagerly is a natural benchmark precisely because it optimizes for the thing usage pricing puts at risk: frictionless, always-on incident response.
PagerDuty's pivot to usage-based pricing is a signal about where the whole category is heading, driven by the reality that AI has broken the economics of charging per seat. The direction likely makes sense for vendors, and for some customers the new model will be fair or even cheaper. But the transition is genuinely disruptive in the near term, and the teams that come out ahead will be the ones that prepare rather than react.
Concretely, use this quarter to model your own consumption, stand up cost observability next to your reliability dashboards, and pressure-test at least one alternative with predictable pricing so you have leverage at renewal. Above all, protect the principle that cost never enters an engineer's decision to escalate during an incident. Reliability is won in the moments when someone pages without hesitating, and no pricing model should ever get in the way of that. Whether you stay with a usage-based incumbent or move to a Slack-native tool like Pagerly, walk into your next renewal with your own numbers, your own benchmarks, and a clear rule that keeps your on-call program fast, healthy, and predictable.
For deeper context on the shift, PagerDuty's leadership has discussed the move from seat-based to usage-based pricing in the context of AI in a recent CIO interview, and independent analysts have covered the early traction and near-term disruption it is creating across the enterprise base. Reading those sources alongside your own usage data is the fastest way to turn a market headline into an informed decision for your team.