Chat with
this content: Summary, Analysis, News...
Subscribe on LinkedIn
PagerDuty: From Hackathon to the Ops of Operations
I. Introduction and Episode Roadmap
It is three in the morning. A phone buzzes on a nightstand in San Francisco. The screen glows with a terse message: "CRITICAL: Payment processing service down. All transactions failing." Within seconds, an on-call engineer jolts awake, reaches for a laptop, and begins triaging the problem. Across the city, a second engineer receives an escalation. In Seattle, a third joins a virtual war room. In ninety minutes, the service is restored. The company's customers never learn how close they came to a complete outage.
This is PagerDuty's world. And this invisible drama plays out thousands of times every single day across the digital economy.
The premise sounds almost absurdly simple: when something breaks, make sure the right person gets woken up and help them fix it. But behind that simplicity lies one of the most fascinating stories in enterprise software. Three former Amazon engineers, frustrated by the chaos of being on-call, pushed their first commit to GitHub on February 18, 2009. From that kernel of an idea, they built a company that went through Y Combinator, raised nearly $175 million in venture capital, debuted on the New York Stock Exchange with a 60 percent first-day pop, and at its peak commanded a market capitalization approaching $6 billion.
Think of PagerDuty as the 911 dispatch system for the digital world. When monitoring tools detect something has gone wrong — a server is overloaded, an API is returning errors, a database is running out of space — PagerDuty is the system that figures out who should know about it, gets that person's attention immediately, and orchestrates the entire response. It does for software infrastructure what air traffic control does for aviation: it takes a chaotic stream of signals and turns it into coordinated human action.
Today, PagerDuty processes billions of events per year, serves over 35,000 organizations, and has built a nearly half-billion-dollar revenue business around the unglamorous but utterly essential work of keeping the internet running. The company has also reached a genuine crossroads — revenue growth has decelerated to single digits, the stock has lost roughly 88 percent of its peak value, management is exploring a potential sale, and artificial intelligence threatens to reshape everything about how operations work.
This is a story about developer tools, about the cultural revolution known as DevOps, about the relentless pressure to keep digital services running around the clock, and about what happens when a company built on a simple, painful problem tries to become something much bigger. It is also, at its core, a story about the difference between being a feature and being a platform — and whether a company that created an entire category can survive the commoditization of that category by the very forces it helped unleash.
The major themes that run through PagerDuty's history are themes that define the modern enterprise software landscape: the tension between best-of-breed point solutions and all-encompassing platforms, the challenge of maintaining developer love while moving upmarket to enterprise buyers, the role of timing and secular tailwinds in company building, and the disruptive potential of AI to reshape established competitive dynamics.
II. The Pre-History: When On-Call Was Broken
To understand why PagerDuty matters, you need to understand the world it was born into. And that world, circa 2009, was — to put it charitably — a mess.
Picture a mid-size SaaS company in that era. They have a dozen servers humming in a data center somewhere. They use Nagios, the open-source monitoring tool that had been the industry standard since the late 1990s, to watch for problems. When Nagios detects an issue, it sends an email. If the problem is critical, maybe it triggers an SMS to a phone number on a spreadsheet that lists who is on-call this week. That spreadsheet is maintained manually in a shared Google Doc. If the person on call does not answer, the escalation policy is informal: someone texts someone else, who calls someone else, who maybe checks their IRC channel — because Slack did not exist yet.
This is not an exaggeration. This is literally how most companies handled operational incidents. The monitoring tools themselves were powerful at detecting problems but primitive at routing the response. They could tell you that a server's CPU was at 98 percent, but they could not figure out who should be woken up about it, whether that person was actually available, what the escalation path should be if they did not respond within five minutes, or how to coordinate the response across multiple teams once the alert was acknowledged.
For readers unfamiliar with the concept of "on-call," it works like this: engineering teams take turns being the designated responder, typically in weekly rotations. When you are on-call, you carry a phone (or in the old days, a literal pager) and you are expected to respond to any critical alert within minutes, day or night. If you do not respond, the alert escalates to the next person in the chain. It is the engineering equivalent of being an ER doctor on the night shift, except the patient is a software system serving millions of users.
The cultural context matters enormously. In the traditional IT operations model, there was a hard wall between the people who wrote the software and the people who ran it in production. Developers threw code over the wall to an operations team, and that ops team was responsible for keeping everything running. This model was already cracking by 2009.
Amazon had pioneered a different approach internally, one that Werner Vogels, Amazon's CTO, captured in a phrase that would become a rallying cry for an entire movement: "You build it, you run it." The same engineers who wrote the code should be responsible for running it in production. If something breaks at three in the morning, the developer who wrote the faulty code should be the one who gets paged.
This philosophy would eventually crystallize into the DevOps movement and later into the Site Reliability Engineering (SRE) discipline pioneered at Google. For non-technical readers, SRE is essentially the practice of applying software engineering principles to IT operations — treating operational reliability as a measurable, improvable feature of the product rather than an afterthought. Google's approach, documented in their influential 2016 "Site Reliability Engineering" book, created a new discipline and a new job title that thousands of engineers now hold.
But in 2009, the tooling was woefully inadequate for a world where software needed to be always on, where outages cost real money, and where the people responsible for fixing problems needed to be reached reliably, instantly, and with the right context.
The rise of Amazon Web Services, which had launched its core cloud services just a few years earlier, was accelerating the transition to cloud-based architectures. More services meant more complexity, more potential failure points, and a far more urgent need for reliable incident response. The old model of a single operations team monitoring a handful of servers was giving way to a world of microservices, distributed systems, and round-the-clock global operations. Someone needed to build the connective tissue between detecting a problem and resolving it. The tools existed at the extremes — monitoring on one end, ticketing systems on the other — but the critical middle, the alerting, routing, escalation, and coordination, was held together with duct tape and prayer.
The cost of getting this wrong was already becoming quantifiable. A 2013 study by Gartner estimated that the average cost of IT downtime was $5,600 per minute for a large enterprise. For a customer-facing e-commerce site during peak traffic, an hour of downtime could mean hundreds of thousands or even millions of dollars in lost revenue. The monitoring tools could detect the problem in seconds. The ticketing systems could track the resolution over days. But the gap between detection and the first human response — the minutes when an alert sat in an inbox or a text went unanswered — was where the real damage accumulated. That gap was the problem no one had properly solved.
Three engineers at Amazon were about to change that.
III. Founding Story: Three Founders, One Insight
The story of PagerDuty's founding does not begin in a garage or a dorm room. It begins in the corridors of Amazon's engineering organization, where three University of Waterloo graduates were living the very problem they would eventually solve.
Alex Solomon, Baskar Puvanathasan, and Andrew Miklas had all worked as software development engineers at Amazon. They knew firsthand what it meant to be on-call. At Amazon, the practice was literally called being on "pager duty" — because engineers carried physical pagers that would buzz when something went wrong. The experience was formative but also maddening. Amazon had built sophisticated internal tools for incident management, but these tools were proprietary, unavailable to the broader market. Outside of a handful of tech giants, the rest of the industry was still stitching together manual processes, email chains, and shared spreadsheets.
Solomon was the strategist and leader. He held a Bachelor of Applied Science in Computer Engineering from Waterloo, class of 2006, and would serve as PagerDuty's first CEO through the company's formative years. Puvanathasan brought deep infrastructure engineering expertise, having worked on backend systems at Amazon and previously at BlackBerry. Miklas was the technical architect, the engineer who designed PagerDuty's original high-availability architecture — a system that, by definition, needed to be more reliable than anything it monitored. If your alerting system goes down when a critical service fails, nobody gets paged, nobody gets woken up, and a manageable incident becomes a catastrophe. That architectural requirement — building something that essentially cannot fail — shaped the entire engineering culture from day one.
The three co-founders quit Amazon and brainstormed ideas by thinking about internal tools that Amazon had built in-house that would be useful to companies of all sizes. Puvanathasan remembered the frustration of carrying a physical pager, the anxiety of wondering whether an alert would actually reach you, and the chaos when escalation policies existed only in someone's head. The realization crystallized: there was no good commercial product for on-call incident management. On February 18, 2009, they pushed their first commit to GitHub. The company name was not the product of a branding exercise. It was simply what Amazon engineers called the rotation: pager duty.
The initial product was elegantly focused. PagerDuty connected to monitoring tools like Nagios and routed alerts to the right person via phone call, SMS, email, or push notification based on configurable on-call schedules and escalation policies. If the first person did not acknowledge the alert within a set time, the system would automatically escalate to the next person in the chain. No spreadsheets. No hoping someone checks their email. No lost alerts. The brilliance was not in any single feature but in the systematic approach to a problem that everyone had been solving with ad hoc workarounds.
The founders launched their beta on Hacker News in August 2009, and the response validated their thesis immediately. Engineers understood the value because they had all experienced the pain. PagerDuty was not a solution looking for a problem; it was an answer to a prayer that thousands of on-call engineers had been muttering at three in the morning while fumbling for their phones.
In the summer of 2010, PagerDuty was accepted into Y Combinator's S10 batch. The three co-founders relocated from Toronto to a cramped apartment off El Camino Real in Mountain View, California. Y Combinator provided more than seed funding — it gave PagerDuty access to a network of technically sophisticated founders and early adopters who were exactly the kind of users the product was built for. In the YC batch, surrounded by other developer-tool startups, PagerDuty refined its pitch: this is the tool that wakes you up when your product breaks and makes sure the right person is handling the problem.
Early customers included some of the most respected names in the emerging cloud ecosystem — companies like GitHub and Twilio, organizations that were themselves building the infrastructure of the modern internet. These were not just customers but evangelists, engineers who told other engineers about the tool that had transformed their on-call experience. The land-and-expand DNA was present from the very beginning: a single team at a company would adopt PagerDuty, other teams would see the improvement in response times and coordination, and within months the product would spread across the organization. The product sold itself because the pain it addressed was universal and the relief was immediate.
What made this organic adoption so powerful was its authenticity. Solomon, Puvanathasan, and Miklas were not building a theoretical solution to an abstract market opportunity. They were building the tool they wished they had at Amazon. Developers could sense that PagerDuty was built by people who understood their world, and that trust proved to be PagerDuty's most durable competitive advantage in the years ahead.
Miklas, the technical co-founder, would go on to become a General Partner at Y Combinator itself, a testament to the caliber of talent in PagerDuty's founding team. Puvanathasan eventually departed to found BorgIQ, an RPA company, in 2019. Solomon remained with the company through its most consequential years, guiding the technical vision through the platform pivot and public offering. The founding team's eventual dispersal was natural and healthy, but the product and culture they established in those early years — obsessive reliability, developer empathy, and organic adoption — remained PagerDuty's defining characteristics long after they moved on.
IV. Finding Product-Market Fit and the Developer Tools Gold Rush
The post-Y Combinator period for PagerDuty was a masterclass in product-led growth before the term was widely used. The company did not need to convince engineers that on-call alerting was important. Every developer who had ever been woken up by a broken system already knew. What PagerDuty needed to prove was that its product was reliable enough to trust with the most critical operational workflow any engineering team has.
Reliability was existential, not aspirational. If your alerting system fails when a critical service goes down, you do not just lose a customer — you lose the entire premise of your product. The team invested heavily in building a system with redundancy across multiple carriers for phone and SMS delivery, failover mechanisms across data centers, and an architecture designed to survive the very kinds of infrastructure failures it was built to detect. In a delicious irony, PagerDuty needed to be the most reliable software product in its customers' entire stack — more reliable than the services it was monitoring. The company maintained contracts with multiple telephony carriers so that if one carrier experienced an outage, alerts could still be delivered through alternative channels. This multi-carrier redundancy was a significant engineering investment but also a competitive moat: building truly reliable notification delivery is harder than it looks, and many competitors cut corners that became apparent only during actual incidents.
The freemium strategy was textbook and effective. Small teams could get started for free or at very low cost. Once PagerDuty became embedded in a team's operational workflow — once the on-call schedules were configured, the escalation policies were tuned, and the integrations with monitoring tools were wired up — expanding to other teams within the same organization was a natural, almost inevitable motion. Each new team created more integration touchpoints, more customized workflows, and more organizational muscle memory.
In 2013, PagerDuty raised a $10.7 million Series A led by Andreessen Horowitz. The a16z imprimatur was a powerful signal — this was the firm that had backed Facebook, GitHub, and a growing roster of developer-tools companies. But the round also brought in Jesse Robbins, co-founder of Opscode (later renamed Chef) and a legendary figure in the DevOps community. Robbins was known as the "Master of Disaster" from his time at Amazon, where he had helped build the company's operational resilience practices. His investment brought deep credibility with the exact audience PagerDuty was selling to. By this point, the company had grown from a handful of founders to roughly 60 employees and was building out its initial executive team.
A year later, in July 2014, Bessemer Venture Partners led a $27.2 million Series B. The milestone behind this round told the story: PagerDuty had crossed $10 million in annual recurring revenue by summer 2014.
That number sounds modest until you consider how it was achieved: driven almost entirely by word of mouth and product-led adoption. The company was not spending heavily on enterprise sales teams or massive marketing campaigns. Engineers were telling other engineers, and the product was expanding within organizations under its own momentum.
The competitive landscape at this stage was fragmented but manageable. Nagios still dominated monitoring but offered no sophisticated alerting. OpsGenie, founded in 2012, was emerging as a direct competitor with similar alert routing features. VictorOps, founded in 2013, focused on collaborative incident management. But PagerDuty had the critical advantages of being first, having the strongest brand in the DevOps community, and accumulating a growing library of integrations with monitoring and DevOps tools.
The pricing model evolved as the customer base matured. Per-user pricing created natural expansion revenue as teams grew, but it also planted a vulnerability that would become painfully visible years later: when companies shrink their engineering teams, seat-based revenue contracts. More significantly, PagerDuty began to recognize that its real value was not just in alerting but in the workflow and coordination that happened after an alert was triggered. Who acknowledges the alert? Who else should be brought in? What context do they need? How is the incident tracked through resolution? These questions pointed toward a much larger opportunity than routing phone calls and text messages.
By mid-2016, the numbers reflected the momentum: 90 percent year-over-year revenue growth, 95 percent year-over-year enterprise revenue growth, and 1,200 new customers added in the first half of the year alone. PagerDuty had established itself as the undisputed category leader. But the insight that would define the next chapter was already forming: being the best alerting tool in the world was necessary but insufficient. If PagerDuty remained a single-purpose tool, it would face the inevitable pressures of commoditization and bundling. The question was not whether to become a platform, but how fast.
V. The Great Pivot: From Point Solution to Platform
In the annals of enterprise software, there is a well-worn script for what happens to successful point solutions. They either expand into platforms, get acquired by larger vendors who bundle their functionality, or slowly watch their position erode as competitors replicate their features and undercut their pricing. By 2015, PagerDuty's leadership could see all three scenarios on the horizon, and they chose to take their destiny into their own hands.
The existential question was stark: "Are we just a pager?" PagerDuty had built a dominant position in a market it had essentially created, but that market was narrowly defined. On-call alerting and scheduling is critical but also relatively simple. The core technology — routing notifications based on schedules and escalation policies — was not defensible through patents or proprietary algorithms. Any well-funded competitor could replicate the basic functionality. And several were trying.
OpsGenie was growing quickly and competing aggressively on pricing. VictorOps was carving out a niche around collaborative incident response. Slack, which had exploded in popularity since its 2013 launch, was becoming the de facto communication hub for engineering teams and adding alerting integrations. Most ominously, the large platform players — Atlassian, ServiceNow, and the emerging observability vendors — were all eyeing incident management as a logical extension of their existing products. In enterprise software, the bundling threat is the most dangerous kind: when a customer can get eighty percent of your functionality included for free in a product they already pay for, your pricing power evaporates.
This was the context in which Jennifer Tejada joined PagerDuty as CEO on July 21, 2016. Tejada brought a background precisely calibrated for the challenge ahead. She had served as CEO of Keynote Systems, a digital performance management company that she led to strong, profitable growth before its acquisition by Dynatrace. Before that, she held executive roles at Mincom in enterprise asset management, at Procter & Gamble, and at i2 Technologies. A University of Michigan Ross School of Business graduate, Tejada combined strategic vision with deep enterprise go-to-market experience — exactly what PagerDuty needed to evolve beyond its developer-tool roots.
Alex Solomon's decision to step aside as CEO and move to the CTO role was a mature and self-aware choice that deserves more recognition than it typically receives. Solomon recognized that the skills needed to build a product and find product-market fit were different from the skills needed to transform a developer tool into an enterprise platform and take it public. He wanted to focus on the technology while bringing in an operator who could reposition the company and scale the business. This kind of clean founder succession is rare and invaluable.
Tejada's strategic reframe was decisive. PagerDuty would no longer be positioned as an "incident alerting" tool. It would become a "Digital Operations Management" platform.
The distinction might sound like marketing semantics, but it had profound implications for the product roadmap, pricing strategy, go-to-market approach, and total addressable market. An alerting tool solves one specific problem for one specific persona — the on-call engineer. A digital operations management platform addresses the entire lifecycle of operational incidents for the entire organization, from detection through response through resolution through post-mortem learning. The TAM for "alerting tools" might be $2 to $3 billion. The TAM for "digital operations management" was estimated at $25 billion or more. Same company, same core product, but a radically different market narrative.
The product expansion unfolded across several dimensions. Event Intelligence, launched in 2016, applied machine learning to reduce alert noise — grouping related alerts, suppressing duplicates, and surfacing the most critical signals from the firehose of monitoring data. This was a meaningful evolution because alert fatigue had become one of the biggest problems in modern operations. Engineers were drowning in notifications, most of which were false positives or low-priority. A system that could intelligently filter and prioritize was worth significantly more than one that simply routed everything indiscriminately.
Response Mobilizer expanded incident response beyond the primary on-call engineer to enable coordinated, multi-team responses for major incidents. Analytics and reporting features gave operations leaders visibility into metrics like mean time to acknowledge and mean time to resolve, enabling data-driven improvement. ChatOps integrations connected PagerDuty with the communication tools where engineers already worked.
In April 2017, PagerDuty raised a $43.8 million Series C led by Accel, explicitly positioned around the platform thesis. Eighteen months later, a $90 million Series D led by T. Rowe Price and Wellington Management set the stage for the IPO, bringing total pre-IPO funding to approximately $173 million.
The platform pivot changed PagerDuty's economic model in ways that matter enormously for investors. A single-purpose alerting tool has a natural ceiling on per-user pricing. A platform that handles the entire incident lifecycle, with intelligence, automation, and analytics layered on top, can command significantly higher prices and drive expansion within existing accounts. It transformed the company from a tool developers adopted bottom-up into a platform that could be sold top-down to engineering leadership and CIOs. It created switching costs that the alerting product alone could never generate: once an organization's incident response workflows, runbooks, escalation policies, and operational analytics are built on PagerDuty, ripping it out is painful and risky.
Most importantly, the platform positioning gave PagerDuty a narrative that could sustain a public company valuation. Wall Street does not get excited about paging systems. It gets very excited about platforms addressing a $25-billion-plus market opportunity in digital operations.
VI. Going Public: The IPO and Public Market Journey
On April 11, 2019, PagerDuty shares began trading on the New York Stock Exchange under the ticker PD. The company priced its offering at $24 per share — above the already-raised range of $21 to $23 — reflecting strong institutional demand. PagerDuty sold approximately nine million shares and raised roughly $218 million. The implied market capitalization was approximately $1.8 billion.
The first day told a story of euphoria. Shares opened at $36.75 and closed above $38, a nearly 60 percent premium to the offering price. PagerDuty was one of the hottest tech IPOs of early 2019, part of a vintage class that included Zoom, Pinterest, Uber, and Lyft.
Within two months, shares reached an all-time high of $59.82 — implying a market capitalization approaching $6 billion. For a company that had generated $118 million in revenue in the fiscal year ending January 2019, that was a heady valuation of roughly 50 times revenue. Andreessen Horowitz, which had led the Series A in 2013 at a fraction of this valuation, saw its pre-IPO stake valued at approximately $284 million — a spectacular return on a $10.7 million round that demonstrated the venture math behind early-stage developer tools investing.
The IPO narrative leaned heavily on the platform thesis and the scale of the digital economy. PagerDuty's S-1 filing painted a picture of a $117 billion digital economy that demanded real-time operational management. The company highlighted its net revenue retention rate above 120 percent — meaning existing customers were spending 20-plus percent more each year, even before new customer acquisition — along with 700-plus integrations and deep penetration among Fortune 500 companies.
But public market life brought new pressures immediately. Wall Street demanded the dual mandate that all high-growth SaaS companies face: grow fast and show a path to profitability. The "Rule of 40" — the benchmark that a company's revenue growth rate plus its profit margin should sum to at least forty — became a key metric investors tracked. PagerDuty's growth was strong but not hypergrowth by SaaS standards, and its path to profitability was measured in years, not quarters.
The competitive dynamics intensified under the public spotlight. Atlassian had acquired OpsGenie for $295 million in September 2018. Splunk acquired VictorOps for $120 million in June 2018. These acquisitions validated the market PagerDuty had created but highlighted the bundling threat. OpsGenie was now available to the millions of teams already using Jira and Confluence. VictorOps, rebranded as Splunk On-Call, was bundled with Splunk's monitoring platform.
After the initial euphoria, shares drifted lower. Revenue grew from $166 million in fiscal year 2020 to $371 million in fiscal year 2023 — healthy compound annual growth of roughly 30 percent. But net revenue retention began its slow, consequential decline from the 120-plus percent levels at IPO. The market was asking harder questions about long-term margins, competitive positioning, and whether PagerDuty could sustain its growth rate as the category matured.
The stock trajectory since the June 2019 peak has been painful. The shares traded in a volatile range through the pandemic era, reaching the mid-$40s during the growth stock euphoria of early 2021 but never recapturing the all-time high. The broader tech selloff of 2022, triggered by rising interest rates and a sharp rotation away from high-multiple growth stocks, hit PagerDuty particularly hard. The stock fell through $20, then $15, then $10 as each successive earnings report showed continued growth deceleration.
As of early 2026, shares trade around $6.50, having touched a 52-week low of $6.18 in late February. The current market capitalization sits at approximately $670 million — roughly one-ninth of the peak valuation. This decline reflects the brutal repricing of mid-growth SaaS companies as interest rates rose, revenue growth decelerated from 30-plus percent to single digits, and investors demanded profitability over growth at all costs.
The irony is that PagerDuty, by most operational measures, has executed reasonably well as a public company. It has expanded its product portfolio, grown its customer base, improved its margins, and recently achieved GAAP profitability. The problem is not that the business is broken; it is that the market's expectations at the time of the IPO were for a different growth trajectory than what materialized.
There is a myth worth dispelling here. The conventional narrative is that PagerDuty's stock decline reflects operational failure. The reality is more nuanced. Revenue nearly quadrupled from the fiscal year of the IPO to fiscal year 2026, gross margins remained in the mid-to-high 80s percent range, the customer base expanded significantly, and the company reached GAAP profitability. What changed was the multiple the market was willing to pay for that growth. At 50 times revenue, the stock priced in a decade of hypergrowth. When growth decelerated from 30-plus percent to single digits, the multiple compressed violently. The business improved while the stock cratered — a pattern that SaaS investors have seen repeatedly across the sector during the 2022-2025 repricing.
VII. The COVID Catalyst and the Remote Operations Era
When the world shut down in March 2020, PagerDuty found itself at the center of one of the most dramatic accelerations in digital transformation in business history. Every company, seemingly overnight, needed to operate as a digital company. Physical retail moved to e-commerce. In-person meetings moved to video. Paper processes moved to software. And all of that software needed to work around the clock, because there was no fallback — you could not just send customers to a physical store if the website went down.
PagerDuty's own data captured the scale of the shift. Critical incidents across its platform increased by 19 percent year over year from 2019 to 2020. That number understates the disruption: the nature of incidents changed, not just their frequency. Healthcare systems needed reliable telemedicine platforms. School districts needed functioning e-learning infrastructure. Government agencies needed working digital services for citizens who could not visit offices in person. The organizations that had treated digital operations as a secondary concern suddenly discovered it was everything.
More than a third of PagerDuty users reported working less consistent hours during the pandemic, with patterns suggesting an average of two extra hours per day — the equivalent of twelve additional weeks of work per year. The boundaries between work and personal time, already blurred for on-call engineers, effectively dissolved.
The remote work dimension added a new layer of complexity to incident response that played directly to PagerDuty's strengths. In a pre-pandemic world, when a major incident occurred, engineers could physically gather in a war room, tap a colleague on the shoulder, or rely on the informal communication networks that supplement any formal process. When everyone was working from home, those informal channels vanished. Suddenly, the formal systems for coordinating incident response — the on-call schedules, escalation policies, communication integrations, and workflow tools — became not merely useful but essential. ChatOps adoption across PagerDuty's platform jumped 22 percent as distributed teams compensated for the loss of physical proximity.
The financial impact was positive but not transformative. Fiscal year 2021 revenue came in at $213.6 million, up 28.4 percent year over year. The growth rate actually decelerated slightly from the pre-pandemic trajectory, which sounds counterintuitive until you examine the customer mix. While many organizations expanded their digital operations, others — particularly in travel, hospitality, and events — slashed spending. PagerDuty also offered concessions and extended free trials to financially pressured organizations, a decision that strengthened long-term relationships but muted near-term revenue. Fiscal year 2022 saw acceleration to 31.8 percent growth, with revenue reaching $281.4 million, as deferred demand converted to paid contracts.
The competitive landscape also intensified during this period. ServiceNow expanded aggressively into AIOps and incident management. Datadog, riding the cloud monitoring wave to a market capitalization that would dwarf PagerDuty's many times over, added incident management capabilities. These were not fringe competitors — they were well-capitalized platform companies that viewed incident management as a natural extension of their existing products and customer relationships.
PagerDuty capitalized on the pandemic disruption, but the honest assessment is that it did not capture a disproportionate share of the opportunity relative to its competitive position. The company grew solidly, but it did not pull away from the competition or establish the kind of market dominance that the moment seemed to demand. This would become a recurring theme: consistently good, rarely breakaway.
The pandemic era also surfaced an important dynamic in PagerDuty's business model. The customer base expanded to over 16,000 companies and 700,000 users by mid-2021. But the nature of that growth was broad rather than deep. PagerDuty was adding customers but not dramatically increasing the spend per customer. The net retention rate, while still healthy above 120 percent, was not accelerating despite the massive increase in digital operational complexity. This suggested that while PagerDuty was essential, it was not capturing as much of the operational management wallet as the platform strategy intended. Customers were using PagerDuty for alerting and basic incident coordination but were not uniformly adopting the higher-tier Event Intelligence and automation products at the pace management hoped for.
As the pandemic-era digital acceleration began to normalize, the question of how PagerDuty would reignite growth became increasingly urgent.
VIII. The AI and AIOps Era: Automation Becomes Intelligence
If the pandemic was a tailwind that PagerDuty rode capably, the rise of artificial intelligence represents a crosswind that could either propel the company to new heights or render significant portions of its value proposition obsolete. The stakes are as high as they have been since the founding.
The core problem AI addresses in operations is one of signal and noise — and to appreciate why this matters, consider the scale of modern monitoring. A typical enterprise application generates an extraordinary volume of telemetry data. Every server reports CPU usage, memory consumption, disk space, and network throughput. Every application reports error rates, response times, and transaction volumes. Every cloud service generates logs, metrics, and traces. The total volume can reach millions of data points per second. Out of this ocean, monitoring systems might generate thousands of alerts per day. Most are noise: brief transient spikes, expected variations, or cascading symptoms of a single underlying problem. The challenge is separating signal from noise — identifying the alerts that actually require human attention and, increasingly, resolving them without human intervention at all.
PagerDuty had been building toward this for years. The Event Intelligence capabilities launched during the platform pivot applied machine learning to reduce alert noise and correlate related events. But it was the company's October 2020 acquisition of Rundeck for approximately $100 million that signaled a serious commitment to automation. Rundeck was an open-source leader in runbook automation — software that allows operations teams to codify their incident response procedures into executable scripts that can be triggered automatically. Think of it as turning the human instinct of "when X happens, I do Y" into software that executes Y automatically when X is detected.
In March 2022, PagerDuty acquired Catalytic for $68.8 million, adding no-code workflow automation capabilities that extended automation beyond IT operations into broader business processes. And in November 2023, the company acquired Jeli for $29.7 million, bringing in incident analysis and post-mortem learning tools that completed the incident lifecycle from detection through retrospective learning. The total acquisition spend across all three deals was approximately $200 million — a reasonable investment for capabilities that materially expanded the platform.
PagerDuty launched PagerDuty AIOps in April 2023, bringing machine learning capabilities into a cohesive product. The results reported by early customers were striking: an 87 percent reduction in alert noise — meaning that out of every hundred alerts, only thirteen required human attention. Automated incident response deployed nine times faster than manual processes. To put that in practical terms: what used to take an engineer thirty minutes of manual investigation and escalation could now be accomplished in under four minutes through AI-driven triage and automation.
In the fall of 2023, generative AI features followed: automated incident summaries in plain English, natural language action recommendations, and AI-assisted root cause analysis. When a major incident occurs and multiple engineers are joining the response, the AI can generate a real-time summary of what happened, what has been tried, and what the likely root cause is — eliminating the costly minutes spent catching up by reading through log files and chat history.
The competitive pressure in AIOps is fierce. Datadog has integrated AI directly into its monitoring-to-incident workflow. ServiceNow's AI-powered IT operations management extends into predictive capacity planning. Splunk, now owned by Cisco following its $28 billion acquisition completed in March 2024, has deep roots in machine learning for operational data. Every major observability vendor — New Relic, Dynatrace, Elastic — has invested heavily in similar capabilities.
PagerDuty's most ambitious AI bet arrived in the second half of 2025 with its end-to-end AI Agent Suite. The SRE Agent, which reached general availability on October 31, 2025, goes beyond recommendations to active participation: it runs diagnostics, surfaces context, suggests remediation, and learns from each incident. Just yesterday, on March 12, 2026, PagerDuty unveiled its Spring 2026 release, pushing toward what CEO Tejada calls "autonomous operations." The headline feature is the SRE Agent evolving into a "Virtual Responder" that can be integrated directly into on-call rotations — meaning the AI agent can be the first responder to an incident, performing triage and potentially resolving the issue before a human is even woken up.
Perhaps most intriguing is the agent-to-agent functionality: PagerDuty's SRE Agent can interact with cloud providers' AI agents, like AWS DevOps Agent and Azure AI SRE, through the Model Context Protocol. This creates what the company describes as a "collaborative multi-agent fabric" where multiple AI agents from different vendors coordinate to diagnose and resolve incidents across complex, multi-cloud environments. Whether this vision translates into revenue or remains a marketing narrative is the central question for the next several years.
The strategic question for investors is existential: if AI can automatically detect, diagnose, and resolve most operational incidents, does the world still need a dedicated incident management platform? Or does it need that platform more than ever — as the coordination hub that connects AI agents, human responders, and organizational processes? PagerDuty is betting on the latter. The answer will determine whether the company's $670 million market capitalization represents deep value or a fair assessment of a narrowing competitive position.
It is worth noting a controversy that briefly overshadowed PagerDuty's strategic execution. In January 2023, when the company announced a 7 percent workforce reduction affecting roughly 66 employees, CEO Tejada drew criticism for quoting Martin Luther King Jr. in the layoff announcement email. The public backlash was swift — quoting a civil rights icon in the context of job cuts struck many as tone-deaf — and Tejada publicly apologized. The episode was a minor but memorable stumble in an otherwise steady tenure, and a reminder that even experienced leaders can misjudge the emotional register of difficult communications.
IX. Business Model Deep Dive and Go-To-Market
PagerDuty's business model has evolved from a simple per-user subscription for alerting into a multi-product platform with tiered pricing designed to drive expansion revenue. Understanding this evolution is key to assessing both the company's strengths and its current challenges.
The product portfolio now spans three main pillars: Incident Management, the core alerting and on-call product; AIOps, which includes event intelligence, noise reduction, and automated triage; and Process Automation, built primarily on the Rundeck acquisition, which enables teams to codify and automate operational procedures. Each pillar has its own pricing tier, and customers can adopt them independently or together. The idea is that a customer starts with Incident Management and, over time, adds AIOps and Process Automation as they mature in their operational practices — a classic land-and-expand motion.
The go-to-market approach blends two strategies that are sometimes in tension. Product-led growth, PagerDuty's foundational DNA, allows individual developers and small teams to sign up with minimal friction, creating a pipeline of potential expansion opportunities. This bottoms-up motion is efficient but slow to generate large deal sizes.
Layered on top is an enterprise sales force that targets larger deals, selling the platform story to engineering leadership and CIOs who can authorize broader deployments and higher-tier products. The challenge is that these two motions can conflict: enterprise sales teams want complex, customizable products that justify premium pricing, while product-led growth depends on simplicity and self-service. Finding the right balance is one of the defining challenges of PagerDuty's current go-to-market strategy.
The per-user pricing model creates a natural growth mechanism when companies add engineers, but it also creates a vulnerability that has become painfully visible. When companies undergo layoffs or efficiency drives — as many technology companies did during 2023 and 2024, right-sizing after the pandemic hiring boom — seat counts shrink and PagerDuty's revenue contracts. This seat compression dynamic is a meaningful contributor to the current growth deceleration.
The partner ecosystem has grown to more than 700 integrations connecting PagerDuty with monitoring tools, communication platforms, ticketing systems, cloud providers, and dozens of other tools in the DevOps stack. Each integration deepens embeddedness in a customer's operational infrastructure, creating switching costs that transcend the product's core functionality. Ripping out PagerDuty means reconfiguring integrations with potentially dozens of other tools, not just replacing the alerting system.
Net revenue retention — the metric that measures whether existing customers spend more or less over time — tells the most important story about PagerDuty's business health and is one of the key KPIs investors should track closely. At the time of the IPO, this metric was above 120 percent, meaning existing customers spent 20-plus percent more each year. It has been on a steady, concerning decline: to 107 percent by fiscal year 2024, to 106 percent by fiscal year 2025, and most recently to 100 percent. A net retention rate of 100 percent means existing customers are, in aggregate, spending exactly the same as a year ago. The expansion engine has stalled.
The company has been growing its base of high-value enterprise customers: 867 customers now spend more than $100,000 annually, up from 825 the prior year. This is the second critical KPI to track — the growth rate of these large-account relationships reflects whether PagerDuty's platform strategy is gaining traction in the accounts that matter most for long-term revenue stability.
On the positive side, fiscal year 2026 — which ended January 31, 2026 — marked PagerDuty's first full year of GAAP profitability, with Q4 net income of $11 million and non-GAAP operating margins in the mid-20s percent range. Non-GAAP gross margins are approximately 87 percent, firmly in premium SaaS territory. The profitability achievement reflects disciplined cost management, including a painful 7 percent workforce reduction in January 2023 that cut roughly 66 positions.
The revenue trajectory tells its own story. From $118 million in fiscal year 2019 to $493 million in fiscal year 2026, PagerDuty roughly quadrupled its revenue. But the growth rate has decelerated steadily: from roughly 41 percent in fiscal year 2020, to 32 percent in fiscal years 2022 and 2023, to 16 percent in fiscal year 2024, to 9 percent in fiscal year 2025, and finally to approximately 5 percent in fiscal year 2026. The company is approaching the half-billion-dollar revenue mark but at a pace that suggests maturation rather than continued hypergrowth. Annual recurring revenue reached $499 million — tantalizingly close to the symbolic $500 million threshold but growing at only 3 percent.
The company can be run profitably at current growth rates — the question is whether profitable stagnation is an acceptable outcome for a company that went public on a growth narrative, or whether it signals the need for a strategic alternative.
X. Competitive Landscape and Market Position
The competitive landscape surrounding PagerDuty has evolved dramatically from the relatively uncrowded niche the company pioneered into a fiercely contested battleground where startups, enterprise platform vendors, and observability companies all vie for the operational management budget.
Consider the irony: PagerDuty's two most prominent direct competitors have both effectively been neutralized, but not in ways that necessarily benefit PagerDuty.
OpsGenie, acquired by Atlassian in 2018 for $295 million, is being shut down. Atlassian ended new sales in June 2025 and plans a complete discontinuation by April 2027. This is a remarkable reversal — the very competitive threat that the bundling thesis warned about has been discontinued, presumably because Atlassian concluded that incident management was not core enough to its platform to justify ongoing development investment.
VictorOps, acquired by Splunk in 2018 for $120 million and rebranded as Splunk On-Call, has received minimal investment since Cisco completed its $28 billion acquisition of Splunk in March 2024. In the vast Cisco product portfolio, a small incident management tool is barely visible.
The two companies that once gave PagerDuty competitive nightmares are both fading — but the threats they represented have been replaced by something potentially more dangerous.
The bigger threat comes from platform players who can offer incident management as one feature among many within a larger suite. ServiceNow, with its market capitalization exceeding $200 billion, competes across IT operations management, IT service management, and increasingly AIOps. Its advantage is deep enterprise relationships and its position as the system of record for IT services in many large organizations. For a CIO already standardized on ServiceNow, adding their incident management module is far simpler than managing a separate vendor relationship with PagerDuty.
Datadog represents a different kind of challenge. As the leading cloud monitoring platform, Datadog has expanded into incident management with on-call and response features. The logic is compelling: if you are already monitoring infrastructure with Datadog and receiving alerts from Datadog, why route them through a separate product? Datadog's market capitalization is roughly 60 times PagerDuty's, giving it enormous resources to invest in development.
A newer generation of startups has emerged as well. Incident.io, a fast-growing company focused on Slack-native incident management, has gained significant traction among modern engineering teams with a more contemporary user experience. FireHydrant and Rootly offer similar modern incident lifecycle tools. These startups target the same developer-first persona that PagerDuty built its brand on, but with interfaces and workflows designed for how engineering teams work today rather than how they worked in 2010.
PagerDuty's defensibility rests on its 700-plus integrations, which represent years of accumulated engineering work that no single competitor can easily replicate. Its brand recognition in the DevOps community, where "getting paged" is colloquially synonymous with PagerDuty, provides organic distribution that money cannot easily buy. Its installed base of more than 35,000 customers and the operational workflows built on the platform create genuine switching costs for deeply embedded deployments.
Where PagerDuty struggles is at the margins of decision-making. Customers evaluating incident management for the first time increasingly consider it as part of a broader platform purchase rather than a standalone decision. Enterprises reducing vendor count may consolidate onto platforms that include incident management as one feature among many. The OpsGenie shutdown represents an opportunity — thousands of displaced customers will need a new home — but it is not clear what share PagerDuty will capture versus competitors who are also aggressively courting those orphaned accounts.
The market size question is central to the investment thesis. PagerDuty frames its total addressable market broadly, encompassing digital operations management, AIOps, and process automation — a market the company estimates at $25 billion or more. Bears would argue that PagerDuty's actual serviceable market is much narrower: the core incident management and on-call scheduling market, which is perhaps $3 to $5 billion. The gap between those two numbers reflects the difference between what PagerDuty aspires to be (a broad platform) and what most customers currently use it for (alerting and on-call management). Closing that gap — getting customers to adopt the full platform rather than just the core product — is the fundamental commercial challenge the company faces.
XI. Porter's Five Forces Analysis
Examining PagerDuty through Michael Porter's framework reveals a company navigating significant structural headwinds but maintaining some defensible ground.
Competitive rivalry is high and intensifying. PagerDuty faces competition from both ends: agile startups like incident.io that innovate rapidly on user experience, and massive platform companies like ServiceNow and Datadog that can subsidize incident management with revenue from larger portfolios.
Basic alerting and on-call scheduling have become commoditized. Most competitors offer adequate noise reduction, escalation policies, and integration with major monitoring tools. The differentiation lies in platform depth, integration breadth, and AI quality — but these distinctions are narrowing as competitors invest heavily. Feature parity in the core product means that competitive battles increasingly play out on pricing, packaging, and platform breadth rather than on the quality of the incident management experience itself.
The threat of new entrants is medium-high. Building a basic alerting tool is not technically complex; open-source alternatives exist, and a capable team can build core functionality in months. However, building an enterprise-grade platform with hundreds of integrations, carrier-grade notification reliability across multiple communication channels, AI-powered intelligence, and the kind of trust required for mission-critical infrastructure takes years of accumulated engineering, customer relationships, and operational data. The barrier is not technology but accumulation.
Supplier power is low — one of the few unambiguously positive forces. PagerDuty runs on standard cloud infrastructure, uses commodity telephony and SMS services, and has no unique supplier dependencies. No input can be weaponized against the company.
Buyer power is medium-high and trending higher. Enterprise customers have significant negotiating leverage, especially as alternatives proliferate. However, once PagerDuty is deeply embedded — integrated with dozens of monitoring tools, configured with complex escalation policies, and woven into the organizational muscle memory of hundreds of engineers — switching costs temper buyer leverage considerably. No CTO wants to swap out their alerting infrastructure and risk missing a critical page during the transition.
The threat of substitutes is high and represents the most significant structural challenge. Substitutes include internal tools built on open-source frameworks like Alertmanager and Grafana OnCall, platform vendors bundling incident management at zero incremental cost, collaboration tools like Slack adding alerting features, and most fundamentally, AI automating away human intervention entirely. If autonomous operations materialize as PagerDuty envisions, the company that makes it happen will capture enormous value — but if a competitor gets there first, PagerDuty's core value proposition of connecting incidents to humans becomes less relevant.
XII. Hamilton's Seven Powers Analysis
Hamilton Helmer's framework provides a more granular lens on PagerDuty's strategic position, and the assessment reveals moderate but eroding competitive advantages.
Scale economies are moderate. Infrastructure costs scale efficiently, and R&D investment is amortized across a larger customer base. But incident management is not a winner-take-all market. There is no structural reason the market must consolidate around a single provider, and the fixed costs, while significant, do not create the kind of scale advantages that exist in search engines or social networks.
Network effects are weak to moderate. PagerDuty benefits from a form of indirect network effect through its integration ecosystem: more customers mean more monitoring vendors invest in PagerDuty integrations, making the platform more valuable for new customers. Within organizations, there is a coordination benefit when multiple teams standardize on the same incident platform. But these are not the self-reinforcing network effects of a marketplace. PagerDuty is a tool, not a network.
Counter-positioning was strong early on but has largely dissipated. In 2010, the incumbents were Nagios and manual processes. Those solutions could not match PagerDuty's SaaS model without fundamentally reinventing themselves. Today, competitors have fully adopted the SaaS playbook, and PagerDuty's approach is no longer counter-positioned against anything.
Switching costs represent PagerDuty's primary source of strategic power. For organizations with deep integrations, complex escalation policies, custom runbooks, and years of operational data, switching is a significant undertaking.
The switching costs are not just technical but organizational — teams have built reflexive habits around PagerDuty's workflows, on-call rotations are configured and tested, and changing all of this introduces operational risk during the transition. Consider the practical reality: a large enterprise might have 50 different monitoring tools feeding alerts into PagerDuty, 200 escalation policies configured across dozens of teams, and hundreds of runbooks codified in the automation layer. Migrating all of that to a competing platform is a project measured in months, not days, and carries the terrifying risk of missing a critical alert during the transition.
Critically, switching costs increase with platform adoption: a customer using basic on-call alerting has low switching costs, while one using event intelligence, process automation, and incident analytics across multiple teams has switching costs that are orders of magnitude higher.
Branding is moderate to strong within the DevOps community but limited in its ability to generate pricing power. PagerDuty has achieved the rare distinction of becoming a verb — engineers say "I got paged" and PagerDuty is the implicit assumption. The brand carries trust and reliability, essential qualities for a product that operates in the most critical moments. But this brand power does not translate into the kind of premium pricing that consumer brands command. Enterprise procurement teams evaluate PagerDuty on features, pricing, and competitive alternatives, not emotional brand affinity.
Cornered resource is weak. PagerDuty possesses no unique data, technology, or talent that competitors cannot eventually replicate. Its accumulated customer data provides some advantage in training machine learning models, but this is not a structural moat. Process power is moderate — the company's product development process is well-tuned to DevOps needs, and its operational reliability is strong. But neither represents a fundamental structural advantage.
The overall assessment: PagerDuty's primary power is switching costs, reinforced by moderate brand strength. These are real advantages that protect the existing customer base, but they are defensive rather than offensive — good at protecting what the company has, limited in their ability to drive new customer acquisition against well-capitalized competitors.
Comparing PagerDuty's power profile to its competitors is instructive. ServiceNow possesses stronger scale economies, stronger process power through its deeply embedded enterprise workflows, and moderate network effects through its ecosystem of implementation partners and consultants. Datadog benefits from stronger counter-positioning in the observability space and growing scale economies from its unified monitoring platform. Even newer entrants like incident.io arguably have counter-positioning advantages — they can build for modern workflows (Slack-native, AI-first) without the legacy constraints that come with maintaining backward compatibility for 35,000 existing customers. PagerDuty's powers are real but not dominant in any single dimension, which explains both the company's resilience (it is hard to dislodge) and its struggle to accelerate growth (it is hard to win new customers against better-positioned alternatives).
XIII. The Strategic Crossroads: Where Does PagerDuty Go From Here
PagerDuty stands at what may be the most consequential strategic juncture in its history. The company has achieved profitability, proved its platform thesis, and built a defensible position with a large customer base. But revenue growth has decelerated to single digits, net retention has flattened to 100 percent, and the stock has lost nearly 90 percent of its peak value. The question is no longer whether PagerDuty can survive, but what form its future takes.
The platform expansion thesis has room to run in two directions. Vertically, PagerDuty can extend from IT operations into business operations — customer service, security operations, and business process management. A payment processing failure is not just an IT incident; it is a customer service incident, a revenue incident, and potentially a compliance incident. PagerDuty's platform can orchestrate the response across all dimensions. Horizontally, the company can push deeper into observability, IT service management, and workflow automation, though this brings it into more direct competition with much larger vendors.
The acquisition question looms large. In July 2025, reports emerged that PagerDuty was exploring a potential sale after receiving inbound acquisition interest. The company engaged Qatalyst Partners, one of the most respected technology M&A advisory firms, to evaluate options. Interest reportedly came from both private equity firms and strategic acquirers. Analysts at TD Cowen estimated a potential acquisition price of $1.9 to $2.5 billion, roughly $19 to $25 per share based on three-to-four times estimated future revenue.
Potential strategic acquirers include companies that would benefit from PagerDuty's customer relationships and integration ecosystem. Microsoft could fold it into its Azure and Microsoft 365 ecosystems, providing a native incident management layer that competes with ServiceNow. IBM, with significant presence in IT operations through its Turbonomic acquisition and Watson AIOps, could add PagerDuty as a complementary layer. Cisco, which now owns Splunk and the remnants of VictorOps, might see PagerDuty as the path to a more comprehensive operations suite — one that combines Splunk's monitoring with PagerDuty's response and coordination capabilities.
Private equity firms represent a different kind of acquirer. PagerDuty's profile — recurring revenue approaching $500 million, gross margins near 87 percent, demonstrated GAAP profitability, and a depressed stock price — is attractive for financial buyers who specialize in taking undervalued SaaS companies private, optimizing their cost structures, and either growing them organically or selling them to strategic buyers at a later date.
As of today, the sale process remains at an early stage with no definitive buyer announced. The stock's continued decline to around $6.50 — well below the speculated acquisition range — suggests the market is skeptical that a deal will materialize at a meaningful premium.
The AI strategy represents PagerDuty's best organic growth opportunity. If the company establishes itself as the orchestration layer for autonomous operations — connecting AI agents from multiple vendors, coordinating automated remediation, and maintaining human oversight for complex incidents — it has a value proposition that is difficult for any single cloud or observability vendor to replicate. The Spring 2026 release with its multi-agent framework points in this direction, but execution and enterprise adoption timelines remain uncertain.
The tension between developer community and enterprise focus will continue to define the company. PagerDuty's DNA is developer-first, and its strongest brand equity is with individual engineers. But revenue increasingly depends on large enterprise contracts where buying decisions are made by executives, not individual practitioners. Balancing these constituencies — keeping the product simple for developers while adding the complexity that enterprise buyers demand — is one of the hardest challenges in software.
Management's vision for the next decade centers on the Operations Cloud concept — a unified platform where human operators and AI agents collaborate to manage the full spectrum of operational challenges, from routine maintenance to complex, multi-system incidents. The credibility of this vision depends entirely on execution: can PagerDuty ship AI products that deliver measurable value fast enough to reignite expansion revenue before the competitive window closes? The next four to six quarters will be decisive.
XIV. Playbook: Lessons for Founders and Investors
PagerDuty's seventeen-year journey offers a rich set of lessons that extend well beyond the incident management category.
The most fundamental lesson is the power of starting with visceral pain. The three founders did not identify an opportunity through market research. They lived the problem every day as on-call engineers at Amazon. The best developer tools companies almost always start this way — with founders building the product they wished they had. This alignment creates authenticity that resonates with early adopters and generates word-of-mouth growth that is nearly impossible to manufacture through marketing alone.
The developer-first go-to-market strategy provides a blueprint that dozens of companies have since replicated, from Stripe to Datadog to Twilio. Let individual developers adopt with minimal friction. Build community through documentation, integrations, and genuine engagement with the developer ecosystem. Allow the product to spread organically within organizations. Then layer on enterprise sales to capture larger deals. This approach generates extraordinarily efficient customer acquisition because the product does much of the selling before a salesperson ever gets involved.
The platform imperative is perhaps the most important strategic lesson. PagerDuty's 2016 pivot from point solution to platform was not optional — it was existential. Companies that remain single-feature tools face two fates: acquisition by a larger platform that wants to add their feature, or slow commoditization as competitors replicate their functionality. By expanding into a platform, PagerDuty gave itself pricing power, expansion revenue, switching costs, and a narrative that could sustain a public company valuation. The lesson applies broadly: founders need to think early about whether they are building a feature, a product, or a platform, and have a credible plan for expanding.
The integration strategy deserves special attention. PagerDuty's 700-plus integrations represent one of its strongest competitive assets. Each integration is an investment in switching costs — a customer who has configured PagerDuty to work with twenty different tools faces a significant effort to replicate those connections elsewhere. For founders building developer tools, the lesson is clear: invest early and heavily in the integration ecosystem, because it compounds over time and creates defensibility that raw product features cannot.
Capital allocation tells an instructive story. The three acquisitions — Rundeck for automation, Catalytic for workflow, Jeli for incident analysis — were each strategically logical, filling gaps that would have taken years to build internally. The total spend across all three was approximately $200 million, a disciplined investment relative to the company's revenue base. This build-versus-buy calculation is one of the most consequential decisions platform companies make, and PagerDuty executed it with reasonable discipline.
The timing lesson is also worth emphasizing. PagerDuty was founded at the perfect moment — the confluence of cloud computing adoption, the DevOps movement, the rise of always-on SaaS applications, and the cultural shift toward "you build it, you run it." These tailwinds carried the company through its first decade of growth. Founders often underestimate the role of timing in their success, attributing to skill what was partially luck. PagerDuty's timing was excellent, but the tailwinds eventually moderated, and the company's growth decelerated as the category matured.
Perhaps the most sobering lesson is about the limits of category creation. PagerDuty essentially invented the incident management category, named it, and led it for years. Yet category leadership alone was not sufficient to prevent competitive pressure, revenue deceleration, and massive valuation compression. Creating a category gives you a head start, not a permanent lead. The moats must be continuously reinforced, and the platform must continuously evolve, or the advantages of being first erode. The second-mover advantage — letting PagerDuty prove the market, then entering with greater resources — has been exploited effectively by multiple competitors.
XV. Bull vs. Bear Case
The investment debate around PagerDuty at its current valuation of roughly $670 million centers on whether the company represents deep value with significant optionality or a structurally challenged business facing secular headwinds.
The bull case starts with market fundamentals. Every organization that operates digital services needs incident management. This is not discretionary spending; it is operational infrastructure. When companies reduce budgets, they cut nice-to-have tools, not the system that wakes up engineers when critical services fail. The total addressable market continues to expand as more industries digitize and as operational complexity increases with microservices architectures, multi-cloud deployments, and AI workloads.
The OpsGenie shutdown removes a major competitive threat and creates a near-term customer acquisition opportunity. Thousands of organizations will need to migrate off OpsGenie by April 2027, and PagerDuty's integration depth and established platform make it a natural destination. If PagerDuty captures a meaningful share of these displaced customers, it could reignite growth and reverse the net retention decline.
The AI opportunity is potentially transformative. If PagerDuty positions itself as the orchestration layer for autonomous operations — connecting AI agents from multiple vendors through its multi-agent framework — it addresses a market orders of magnitude larger than traditional incident management. The valuation provides a compelling entry point: at roughly 1.3 times annual recurring revenue, PagerDuty trades at a fraction of the multiples commanded by comparable SaaS companies. Gross margins near 87 percent and demonstrated GAAP profitability provide downside protection. In an acquisition scenario, the recurring revenue base, customer relationships, and integration ecosystem could command three to four times revenue, representing substantial upside.
The bear case is equally forceful and should not be dismissed. Revenue growth has decelerated from over 30 percent to approximately 5 percent, and net retention at 100 percent means existing customers are no longer expanding. This is not a growth company by any SaaS metric, and the deceleration appears structural rather than cyclical — driven by category maturation, seat compression, and competitive displacement rather than temporary headwinds. The revenue growth trajectory — 41 percent, 28 percent, 32 percent, 32 percent, 16 percent, 9 percent, 5 percent over successive fiscal years — is a consistent downward staircase with no sign of inflection.
The bundling threat, while mitigated by OpsGenie's departure, remains the most significant strategic risk. ServiceNow, Datadog, and the major cloud providers all offer or can offer incident management as part of broader platforms. For enterprises reducing vendor count, the standalone incident management vendor is a natural consolidation target. The moat analysis reveals limited structural defenses: switching costs protect the existing base but do not drive new acquisition, brand does not generate pricing power, and network effects are weak.
AI represents both opportunity and threat. While PagerDuty invests heavily in AI capabilities, so does every competitor. The observability vendors, cloud providers, and ITSM platforms all have access to similar or larger datasets, deeper customer relationships for distribution, and greater financial resources. If AI commoditizes incident management further by automating response, the human-facing coordination layer that PagerDuty sells becomes less valuable, not more.
The three KPIs that matter most for tracking PagerDuty's trajectory going forward are: net revenue retention rate, which reveals whether the existing customer base is healthy and expanding; the number of customers spending more than $100,000 annually, which reflects enterprise platform adoption; and the revenue contribution from AI and automation products, which will signal whether the company's strategic bets are translating into financial results. A sustained reacceleration of net retention above 105 percent would indicate the platform expansion strategy is working. Stagnation at or below 100 percent confirms the structural growth challenge.
XVI. Recent Developments and Future Outlook
The most recent chapter of PagerDuty's story is being written in real time. Yesterday, March 12, 2026, the company reported fourth quarter and full fiscal year 2026 results. The headline was significant: PagerDuty achieved its first full year of GAAP profitability in its history. Fourth quarter GAAP net income was $11 million, marking the third consecutive quarter of GAAP profit. Earnings per share of $0.29 beat the consensus estimate of $0.24.
The growth picture remained sobering. Full-year revenue was approximately $493 million, up about 5 percent from the prior year. Fourth quarter revenue of $125 million grew just 3 percent year over year. Annual recurring revenue reached $499 million — tantalizingly close to the half-billion milestone but growing at only 3 percent. The net retention rate declined to 100 percent.
The product announcements were far more exciting than the financial results. The Spring 2026 release laid out a roadmap toward autonomous operations that stands among the most ambitious in the industry. Making PagerDuty's SRE Agent a first-class member of on-call rotations — capable of being awakened before human engineers, performing initial triage, and potentially resolving incidents autonomously — represents a genuinely novel approach. The expansion of the AI ecosystem to include more than 30 integration partners, with agent-to-agent capabilities connecting PagerDuty's AI with AWS and Azure AI agents, positions the company at the center of an emerging multi-agent operations architecture.
Leadership evolution continues to shape the organization. Todd McNabb joined as Chief Revenue Officer in September 2025, bringing fresh go-to-market perspective. Scott Aronson joined the board in February 2026. CEO Jennifer Tejada, approaching her tenth anniversary at the helm, remains the primary architect of strategic direction.
The M&A exploration reported in July 2025 has not produced a transaction. Qatalyst Partners was engaged, and interest reportedly came from both private equity and strategic acquirers. The absence of a deal despite the stock's continued decline could mean several things: the board may have rejected offers below its price expectations, potential acquirers may be waiting for further price deterioration, or the strategic fit may not be compelling enough for any single buyer at the prices discussed.
One underappreciated catalyst is the OpsGenie shutdown. Atlassian's decision to discontinue the product by April 2027 eliminates a significant bundled competitor and creates a pool of migrating customers. PagerDuty has actively positioned itself to capture this migration, and the financial impact should begin appearing in fiscal year 2027.
The macro environment presents a mixed backdrop. Enterprise technology spending remains cautious, favoring incumbent platforms over standalone vendors. But the AI investment wave is driving demand for operational infrastructure capable of supporting AI-driven workloads and autonomous systems, a potential tailwind for PagerDuty's vision.
There are material risks worth flagging for investors tracking this story. The sale exploration process that began in July 2025 introduces uncertainty about management's commitment to the independent path — if the board is actively evaluating offers, how aggressively will they invest in the AI roadmap? The seat-based pricing model faces structural headwinds as enterprises automate more and staff fewer human operators. And the competitive landscape continues to shift: Cathie Wood's ARK Invest made a notable purchase of PagerDuty shares, signaling some institutional contrarian conviction, but the broader market sentiment remains skeptical given the growth trajectory.
The autonomous operations future that PagerDuty envisions raises a profound question about human intervention in technology operations. As AI agents resolve an increasing share of incidents without human involvement, the on-call experience will fundamentally change — from primary response to supervision. The company's pricing model and strategy will need to evolve to capture value when the "pager" in PagerDuty increasingly rings for a machine rather than a human.
XVII. Epilogue: The Unsung Hero of the Digital Economy
There is a quiet irony at the heart of PagerDuty's story. The company built its business on the premise that someone needs to be woken up when things go wrong, and its ultimate strategic vision is a world where no one needs to be woken up at all. If autonomous operations succeed, PagerDuty will have solved the very problem that gave it its name — the burden of carrying a pager — and will need to find its value in the orchestration and intelligence layer that sits above human response.
PagerDuty occupies one of those hidden but critical roles in modern life that most people never think about. Every app on a phone, every streaming service, every banking platform, every ride-sharing application has someone — or increasingly something — watching over it. When these services work flawlessly, which is most of the time, nobody thinks about the operational infrastructure keeping them running. When they fail, the quality and speed of the response determines whether customers experience a momentary hiccup or a front-page outage.
The human side of this story deserves reflection. On-call culture has been a source of burnout, stress, and work-life disruption for millions of engineers over the past two decades. Being on-call means that at any moment, day or night, weekday or weekend, holiday or vacation, your phone might ring with a problem demanding immediate attention.
The psychological burden of constant availability is real and measurable. Studies have shown that even when nothing goes wrong during an on-call shift, the state of heightened alertness — knowing that your phone could ring at any moment — reduces sleep quality and increases stress hormones. PagerDuty's own data has consistently documented the toll: irregular hours, disrupted sleep, and the cognitive weight of maintaining perpetual operational awareness. Industry surveys have found that on-call burnout is one of the leading causes of engineer attrition, particularly among senior engineers whose expertise makes them the most valuable (and most frequently paged) responders.
If PagerDuty's AI agents can genuinely reduce the frequency and severity of human pages, that is not just a business outcome — it is a quality-of-life improvement for hundreds of thousands of engineers worldwide.
PagerDuty's journey from three engineers tired of carrying pagers to a half-billion-dollar-revenue platform company tells a broader story about the infrastructure layer of the digital economy. The most valuable technology companies in the world — the ones that capture headlines and public attention — are built on top of an invisible foundation of operational tools, monitoring systems, and incident response capabilities. This infrastructure is unglamorous, rarely discussed outside engineering circles, and absolutely essential.
At $493 million in revenue, 35,000 customers, more than 700 integrations, and now GAAP profitability, PagerDuty has earned its place in the story of developer tools companies that successfully transitioned from point solution to platform.
The company's story contains a tension that makes it compelling for investors to study regardless of where the stock goes next. PagerDuty did almost everything right — identified real pain, built a beloved product, expanded into a platform, went public, achieved profitability — and still finds itself at a market capitalization below its Series D valuation. The lesson is not that PagerDuty failed. The lesson is that even excellent execution cannot overcome structural market forces: commoditization, bundling, and the relentless compression of standalone software multiples in a world dominated by platform consolidation.
Whether the next chapter involves an acquisition, a return to growth through AI, or continued existence as a profitable but slow-growing independent company, the impact on how the world manages digital operations is undeniable. Every time a favorite app works as expected, somewhere in the background, someone — or something — is on pager duty.
XVIII. Further Learning
The PagerDuty S-1 filing from 2019 remains essential reading for understanding the business model, competitive positioning, and growth trajectory at the time of its public listing. "The Phoenix Project" by Gene Kim, the DevOps novel that defined the movement, provides critical context for the cultural and technical shifts that created PagerDuty's market. Jennifer Tejada's conference talks and interviews offer direct insight into the platform vision that guided PagerDuty's transformation from alerting tool to operations cloud. Google's "Site Reliability Engineering" book, often called the SRE bible, explains the operational discipline that PagerDuty's products support. "Accelerate" by Nicole Forsgren, Jez Humble, and Gene Kim provides the empirical research behind DevOps practices and their impact on organizational performance.
For market and financial context, the Bessemer Cloud Index and accompanying SaaS metrics guides are invaluable for evaluating PagerDuty relative to its SaaS peers. Gartner's Magic Quadrant for IT Operations Management and AIOps provides independent competitive positioning analysis. Developer community discussions on Reddit's r/devops and Hacker News offer ground-truth perspectives on how engineers evaluate and compare the product to alternatives. PagerDuty's own annual State of Digital Operations reports provide data-driven insights into incident management trends. The "DevOps Handbook" by Kim, Humble, Debois, and Willis rounds out the technical foundation with practical implementation guidance for the practices that make PagerDuty indispensable.
RSS Feed
Spotify
Apple Podcasts
Amazon Music
Audible
YouTube