PagerDuty feels like abandonware. It hasn't changed in the last 4-5 years.
They're spending $30M+ on R&D, so if you feel that way as a customer, that's not good.
PagerDuty S-1
21–30 of 194 posts
Re: PagerDuty S-1
#22> If we fail to offer high-quality support, our business and reputation could suffer. I don't know how common this is in S-1 filings but it stuck out to me. Support is often viewed as a cost center, I love that PagerDuty makes it such a high priority. Edit: After some research, it turns out this is common. Docusign, Dropbox, Okta, Zuora, and MongoDB all have this statement exactly or similar.
I can vouch that Support & Customer Success has always been a first class participant in the company. One of the founders ran the team when it was small, and Ryan has done a great job growing it out -- to the point where their #1 problem is other PD teams poaching their people into other roles in Product, Internal Tools, Engineering and even Sales :)
(Disclaimer: I worked at PagerDuty for 7+ happy years)
Re: PagerDuty S-1
#23PagerDuty feels like abandonware. It hasn't changed in the last 4-5 years.
They're spending $30M+ on R&D, so if you feel that way as a customer, that's not good.
On principle alone I wouldn't give them my money ever again. I'd engineer my own lightweight solution before then or use an underdog competitor. I have a sour taste in my mouth for their meteoric rise to success/IPO versus their pathetic investments (or lack therof) in product improvement. It really sucks to use. Reminds me of Engineyard (also abandonware).
Re: PagerDuty S-1
#24PagerDuty feels like abandonware. It hasn't changed in the last 4-5 years.
What are they doing with all those R&D dollars?
Re: PagerDuty S-1
#252017: $79.6M revenue, ($38M)in losses. 9 months of 2018: $84M revenue, ($34.5M) in losses. Costs seem generally under control except the significant growth (+66%) in G&A expenses. Why the hurry to IPO?
Liquidity for one.
Conditions for an IPO are rarely perfect - you need to have the right internal situation, the right market conditions etc. etc. - so if the company is thinking of doing an IPO, and they can ... well then they're going to lean towards doing it.
VC's can cash out if they want and pass the buck.
That said, if they only have some major 'one time cost' dragging down earnings, and earnings will be spectacularly better next year ... it might be worth the wait. But even then - if the IPO suffers a little, but then rockstar numbers come out later, the stock will go up. So VC's that want to hold on have the option to do that.
Re: PagerDuty S-1
#26PagerDuty feels like abandonware. It hasn't changed in the last 4-5 years.
[deleted]
Re: PagerDuty S-1
#27Interesting that they reference their Glassdoor rating: The strength of our culture is key to attracting and retaining the best talent, as demonstrated by our high employee retention rates, and, as of January 31, 2019, a Glassdoor rating of 4.5 out of 5 and 100% approval rating of our chief executive officer.
Uh, that is a big negative sign for me, because they have an an "employer active" account. In other words, they pay for the privilege to get reviews deleted.
> 100% approval rating of our chief executive officer.
So I am 99.99% sure that HR was tasked with removing bad reviews ;-)
Re: PagerDuty S-1
#28I run a service that integrates with pager duty on behalf of our users, and man oh man did they make some poor design choices with their API.
The most glaring one is their integration keys, which is how you trigger an alert. They’re just v4 uuids with the hyphens removed, or in other words, completely random.
This is fine by itself, except they have two versions of their event API, and keys for the v1 API don’t work with v2 and vice versa. And there’s no way to distinguish what version a given key is for, since it’s just a jumble of bytes. We can’t even look up the service integration to find out what version it should be. We can using yet another different API, but even then it’s not clearly distinguished.
So now our users are confused about what version they should use. We only supported v1 for a while since there was no way to distinguish, but users kept using v2, which was failing cryptically.
So now we need to try v1, and if it fails try v2. But that means that our monitoring on errors are all fucky now since half the errors arent real errors.
In the grand scheme of things I guess it’s a relatively small design issue, but it sitting right in the middle of their one and only critical path, which makes it really painful.
I’ve alrwady contacted support about it and their response has been, more or less, “oh, uhhh... huh.”
Re: PagerDuty S-1
#29Earlier quoted context omitted.
Good market now, bad market likely in a year or two.
Why do you think bad market likely in a year or two?
We're way overdue for a recession, there are already signs of slowing, and historically after massive tax cuts for the rich, a recession follows a couple years later after the piper has to be paid. Signs all point to a recession in one to two years.
Re: PagerDuty S-1
#30I run a service that integrates with pager duty on behalf of our users, and man oh man did they make some poor design choices with their API. The most glaring one is their integration keys, which is how you trigger an alert. They’re just v4 uuids with the hyphens removed, or in other words, completely random. This is fine by itself, except they have two versions of their event API, and keys for the v1 API don’t work…
Do the same calls to the same APIs from the same customers ever change from v1 to v2 (or vice versa)? If not, can you record if it was v1/2 and then always make the same call after that? And then don't record errors for your initial probe request? Then your data will be clean and you'll make a lot less calls.