The founding story of PagerDuty hinges on a small detail: the founders often joke that if pagerduty.com had already been taken, they might have scrapped the idea entirely. The available domain felt like a signal. It was 2009, and three Amazon software engineers in Toronto - Andrew Miklas, Alex Solomon, and Baskar Puvanathasan - had noticed something everyone around them was ignoring: the biggest tech companies on earth had all built internal on-call systems, and nobody had built one for the market.
Amazon, where all three worked, was in the middle of a dramatic architectural shift - from a monolithic codebase to microservices, with smaller teams owning their code end-to-end, including being on-call for production incidents. The pager went everywhere with you. The alert woke you up at 2am. There was no elegant software managing any of it. Google had built something internal. Facebook had, too. The gap was obvious once you knew to look for it.
On February 18, 2009, the three colleagues pushed their first commit to GitHub. A few months later, they launched a beta on Hacker News. Those early beta testers - engineers with the exact problem PagerDuty solved - became their first paying customers. No sales team. No marketing budget. Just a product that engineers immediately recognized as something they needed.
By 2010, PagerDuty had enough traction to get into Y Combinator's Summer batch. The team packed up and moved from Toronto to San Francisco. They raised $1.9M in seed funding. And Andrew, as founding CTO, set about designing a system that had to be genuinely resilient - the kind of platform that couldn't go down precisely because its job was to tell you when everything else was going down.
The architecture Andrew built for PagerDuty had a demanding brief: handle alerts from any monitoring system, route them to the right person via any channel, escalate if the first responder didn't pick up, and do all of this without ever going offline. The failure mode - PagerDuty's own product failing to deliver an alert - was the worst possible outcome. He built something that worked.
Over the next decade, Andrew scaled the engineering team from the original three founders to more than 70 people. PagerDuty crossed $100M in annual recurring revenue, signed 10,000+ customers, and became the default incident response tool across enterprises. In April 2019, PagerDuty rang the NYSE opening bell. Market cap at debut: $1.8 billion.
After stepping back from PagerDuty's day-to-day, Andrew moved into early-stage investing at s28 Capital, the firm focused on backing technical founders building developer tools and infrastructure. His portfolio there - Clerk, CaptivateIQ, Teleport - signals exactly what kind of operator he's become: he looks for companies solving the specific engineering problems he once had, and bets on technical founders who understand their domain the way he understood his.
Around 2024, Andrew started spending time at Y Combinator as a Visiting Group Partner. For someone who'd been through YC as a founder, worked closely with the community as an investor, and spent years advising YC alumni including Mattermost, Retool, Gem, and Infisical - the role fit naturally. He became one of the most trusted voices in multiple batches.
In May 2025, fifteen years after first arriving at YC with a pager startup and a GitHub repo, Andrew was named a General Partner. He came back alongside Jon Xu, another S10 classmate who'd built FutureAdvisor. Two founders from the same batch, two companies that defined their respective industries, both returning to run the thing that helped them start.
As a General Partner, Andrew selects startups for investment, guides founders through the early stages, and shapes the direction of a program that accepts companies from every technical domain. His particular focus stays consistent: startups building tools for software engineers and operations teams, B2B companies with serious technical depth, and founders who learned their problem from the inside before trying to sell the solution.
That bias is earned. Andrew knows what it costs to build a system that can't go down. He knows what it feels like to scale from three engineers to seventy while maintaining the culture and the architecture. He knows the specific kind of pain that makes an engineer quit their job and start a company - because he was that engineer, twice over: once when he left Amazon, and again when he left PagerDuty to back other operators trying to do the same thing.
The YC community sees him as a practitioner, not a theorist. His advice on resilient systems doesn't come from reading about them. His perspective on scaling engineering teams didn't come from an MBA. And his judgment about which technical founders are ready - that comes from having been one, and having watched hundreds more up close.
