After 12 years of being a customer, Uber is dumping PagerDuty

twitter.com

9 points·tosh··5 comments

It would be relatively easy to build the logic for on-call rotations, and to build the API endpoints for consuming alerts. But add to that the work of also building mobile apps, working with SMS and email infra, and this becomes a non-trivial effort. For a company like Uber it might make sense to dedicate a tiny team to build an in-house solution. For small startup, it still is not worth the hassle to maintain a service like this in house.

Bonus question - how do you alert your team that your home-build PageDuty went down?

I would guess they kept a small amount of SREs with Pagerduty access (or other third-party service) to monitor this system, or built another simpler alert system to monitor it.

They definitely aren't dropping on-call rotation entirely, so what are they replacing it with?

I'm a happy PagerDuty customer, but also in the 90's we just did stuff like that with some she'll scripts. It's not rocket science, if you don't care about a bunch of metrics, etc.

So, I wonder if this is an instance of the agentic coding SaaS-pocalypse.

Ex-PagerDuty here. Without weighing in on the criticisms of pricing and innovation with the product, I will say that the value of PagerDuty is its reliability in notifying you when it receives a signal from a system. Rebuilding the product isn't just asking an LLM to spit out a web app to do scheduling, it's in the notification pipeline (SMS, email, push notifications, Slack), maintaining all that and mobile apps too.

Just like Uber itself, this is one of those "I could replace this in a weekend" things that doesn't actually pan out that way.

Reply on news.ycombinator.com