Rate my startup: PagerDuty.com
If you've ever done pager/on-call duty, you're probably familiar with a tool like PagerDuty. PagerDuty collects email alerts from your monitoring tools and sends out automated phone calls and SMS messages to the person currently on-call. The app supports many of the usual amenities in an alerting system, such as retry of unanswered alerts, on-call rotations, and automatic escalation of unanswered alarms.
Many large tech companies like Google and Amazon have sophisticated in-house on-call management and alerting systems. We have tried to build something similar for small and medium-sized businesses running critical systems.
One of the big challenges in building PagerDuty was making it simple and intuitive to use. If you find the setup process (or any other part of the system) confusing please let us know.
http://www.pagerduty.com
82 comments
[ 1071 ms ] story [ 394 ms ] threadPerhaps they should A/B test the logo - try http://www.markiter.com (shameless plug)
In five to 10 seconds the copy & design conveyed the site's purpose. I got it and thought cool - there is a need for this utility!
good luck!
We have tried to offer a SaaS solution aimed at small and medium businesses.
http://www.reliableresponse.net
http://peashootapp.com/
For the application site, we started with the open-source Web App Theme (http://github.com/pilu/web-app-theme/tree/master) and changed it to suit our needs.
A couple suggestions...looking at your prelim pricing page, the prices look good, but I can foresee a problem with the notification system that accidentally sends way too many alerts. How will you accommodate that? It would be nice to have a grace period or some way of saying, ok we realize it was a mistake, we'll let this one slide but the next time you will be bumped up automagically to the appropriate pricing plan.
Also how easy is it to integrate with existing notification tools like Nagios or Cacti? Or is it just tied to email notificatons from those systems? That would be a downside if it's the latter. I've worked at orgs with truly crappy email systems that are down more often than not. Sending an email blast for a production system outage is likely to get it canned by the sysadmins.
Finally how does the phone call alerting work? Is it text-to-voice? Or pre-recorded messages? Is it customizable?
As for the pricing plans, we don't plan to bump you to the next plan if you exceed the limits. We have overage prices for each type of message (phone/SMS). So, going slightly over your quota isn't going to cause a really big bump in your fee.
Currently, PagerDuty only integrates with monitoring tools using email. We do have several customers sending their Nagios alerts to us. We are also planning to build a Nagios plugin to better integrate Nagios with our system.
We haven't actually found the email integration to be a big problem so far. What some of our customers do is set up some external network monitoring tool (i.e. Pingdom) to make sure their mail servers are up and running. Those services are in turn hooked up to a PagerDuty alarm so that we can notify the right person if a site's mail server or external connectivity fails.
Phone call alerting is text-to-voice. It tells you which alarm went off, and also reads you the subject of the error. What kind of customization are you thinking of?
I halfway expected there to be a portion of Nagios' features built in, at least the ones that make sense for services open on the internet: like ping, socket, and HTTP availability.
I guess your intended focus is to be purely a distribution mechanism for existing alerts -- which isn't very useful for just one person -- especially since I'd have to set up separate offsite monitoring systems to generate the alerts I care most about.
Let's say I already have an existing monitoring service that sends emails on network events. I might decide to hook in your service and send my network faults there.
I get "port XX on switch YY link state down" and that gets routed through the system. One minute later I get "office of the CEO video conference network down" but pagerduty never sends that to my mobile device because I'm busy looking at the one port down alert.
Yes, I realize there's a technical solution to create multiple pagerduty trigger email addresses, but at a minimum, I'd encourage you to be more clear about that feature/limitation.
Overall comments: several UI elements were "not pretty" looking on IE7, and some of the call to action graphics "Create your first alert now" were bright yellow and rectangular yet not clickable. No deal-breakers, and I was certainly able to quickly get setup and trial alerts coming.
We actually support having the same email address for multiple alarms in the system. We also have regex trigger rules for each alarm, which are based on the subject and/or body of the trigger email. This means that you can set up a single email address, and trigger one alarm if "port XX on switch YY" is down, and trigger a different alarm if the "CEO video conference network" is down.
It might be easier to discuss your requirements over email. My address is alex[at]pagerduty[dot]com.
As an aside, I find the best way to avoid regular failures and decrease the necessity for a large operations staff is to put the individuals responsible for building the system on-call for when it fails. Your operations staff is woken up when a server crashes or a hard drive fails, and your engineers get woken up when their code crashes in the middle of the night.
If you don't do this, the costs of writing poor production code have to be levied across departments by management, rather than avoiding externalities entirely and letting engineers and operations deal with the direct impact of their implementation choices.
Of course, this is ultimately a wash if you don't also institute development methodologies to help reduce the number of production-impacting bugs, rather than simply relying on engineer's reactive fixes to one-off issues.
The value is that when support staff has real phone numbers available to them, they tend to dial historically responsive individuals directly in order to get a problem resolved, thus creating a negative feedback loop -- if you ignore notifications and phone calls, you get called less by support staff in the future.
Having a floating number -- especially if we could get statistics on who answers and who always ignores them, and if the number could "call up the chain" automatically when nobody answers, would be a useful tool to solve this issue.
Of course, the preference is that human staff doesn't need to call anyone, but it still happens.
That's an interesting idea. We've actually thought a bit about adding phone-based triggering to PagerDuty (via a 1-800 number + access code). The idea was to make PagerDuty useful to non-IT businesses like plumbers that also have the concept of out-of-hours on-call duty. From your comment, though, it sounds like this kind of feature would be pretty useful even in the IT world.
This encourages the following:
- Closer correlation between business robustness requirements and software implementation.
- Adoption of more robust design or methodologies when required by the business. If all that is required is an automated restart, then automatically restart the software. If the same class of bugs causes regular failure, adopt a strategy for avoiding that class of bugs.
- A realistic platform for negotiating external support. If engineering staff is unable to produce software sufficiently robust as to support the business requirements, then we must make a business decision as to decide whether maintaining additional operations staff is cheaper -- in the short and long-term -- than correcting the engineering issues.
In my experience, software that fails regularly enough to cost significant engineering resources in responding to those failures is generally broken software. The goal is to not let software get to that point, and to correct it quickly if it does.
It's very easy for your Operations budget to unnecessarily balloon under the load of supporting failure-prone software; engineering has every incentive to externalize the costs of their implementation decisions, while operations has every incentive to increase their headcount and budget by supporting those failure-prone systems.
With either the newly oncall or the previously oncall being able to update the number, that handoff now becomes virtual.
We've actually been anxiously waiting to try out Google Voice up here. Unfortunately, they haven't yet extended their coverage to include Canada.
Your front page is very busy. There's many different kinds of text and pictures in so many places, I don't know where to look. Does the "feedback" link need to be in such an unusual place? I understand that you want to convince potential customers that your product is a good one, but if you throw too much information at people, they'll ignore everything you have to say.
I do like the idea of making the design more minimal. I guess we are somewhat worried about the possibility of not explaining well enough what our product does.
Consider the amount of "special" things you have:
- Floating feedback link on the left
- "Sign Up" link/tab is highlighted red. (This also means I have to use some small cognitive effort to realize "Home" is black because I'm there, "Sign Up" is highlighted, and the rest are normal links.)
- "call you" in the blue banner is both bold and italic
- Lead-in text is bold
- "calls you" in lead paragraph is bold, italic and green
- green check marks for the features list
- Play button on your UI graphic
There's nothing inherently wrong with any one of these things, but they're all design elements that say "I'm important! Look at me!" But when I see seven competing things evenly spread out over the page saying "Look at me!" my first reaction is to give up and look at nothing.
I think it's possible to include the same amount of information, just presented in a clearer way. Personally, I think the star of your show are your UI pictures.
Of course, keep in mind I am, like you, a hacker, not a designer. But I'm taking the time to explain what I see because I think you've come up with a neat idea for what sounds like an untapped market, and I'd hate to see you run into problems because of simple presentation issues.
As for the other points. Well this is clearly a 37 signals approach. If nothing else, it is good for SEO. I think most users will click on the video first anyway. So all the content acts to complement the video, which is a good thing.
It is linked off of the FAQ, from the question "How much are you planning to charge for PagerDuty?". We didn't make any links to the pricing page off the main page because we want as many people to try the product out while we are in beta.
1. Have the lightbox title text be more readable. Right now it is white on whatever is on the page.
2. Have the call to action at the bottom of the page favor the sign up process. I would reuse the green button from the top of the page and leave the "learn more" link as text.
3. The email based integration feature is fairly meaningless on its own. It is redundant if it is covered 3 items down with "Alerts via phone call, SMS, and email" I would personally cull out the overlap and have just a few key features on the right. Really only put the stellar features that you offer.
4. To keep the logo more web 2.0 like the rest of your interface I would have the text framed in what looks like a pager but make the pager look 2.0ish.
Overall it looks as if this might be successful. I am not really in the market for it but I could see some smaller businesses jumping on board.
Another option would be to have a purely prepaid plan, where your account gets debited based on alarms/users per-period, and per-incident. I'm definitely going to use this service while it's free, but I don't think I'd pay $120/year for it unless I had a web startup.
One thing I'm wondering about is why you have no international calls. I would love to pay (a lot) more money if you could support international calls. Without that, the service is only half as useful, and I will sleep only half as good during the night. :-)
Do you have any plans for a packaged version which companies can host themselves?
The reply via SMS feature is excellent and something that I always want in any monitoring system.
I'm curious about the security around the email alerts, can anyone send to the specific trigger-alarm@mysite.pagerduty.com or can you add at least a 'FROM:' check?
You probably have this on your road-map, but if a ticketing/worklog system could be integrated with this, you could add an incredible amount of value for folks working on the problem in real time.
Overall great idea with PagerDuty though, especially if one's business relies (survives) on their website's/system's uptime. Reducing MTBF is often very hard, especially after a certain point, and reducing MTTR is therefore very important for improving availability.
The email addresses for alarms are editable; if you get spam to one of these addresses, you can change the address. We were also thinking of adding an option to obscure the email address by adding a uid to the end. An example would be trigger-my-alarm-5j3rt@acme.pagerduty.com.
We also offer regex-based filters on both the subject and the body, so you can configure an alarm to only trigger if a certain keyword appears in the message.
Granted, I'm thinking of monitoring systems on a much larger scale where even a single instance of spamming can keep the entire dev team up at night. I do not see this being a problem for the smaller targeted audience that you are going after that will initially only set up a handful of alarms.
The yellow boxes under "Follow these steps to get started..." look a little godaddy-ish
As for the getting started steps looking godaddy-ish, is that a compliment? :P
We use Wormly to monitor our site, email and DNS. We also have an exception reporting system which alerts us about any 500 errors in the site. We also alert if phone call or SMS messages sit in our event queues for more than 3 minutes after the scheduled delivery time.
We also have redundant data centers and rapid rollover to the backup systems in the event of a data center outage.
We don't use PagerDuty to do the alerting and schedule the on-call though. We alert everybody in our team via SMS and phone if any of the aforementioned alerts go off.
I would make "phone calls, SMSes, and emails" much more prominent though. It took me too long to find how I would actually be alerted. There is a lot of fuzzy text on the site that makes it hard to scan.
I really like this service and should the escalation change I would sign up in a heartbeat, it's exactly what I was looking for.
We left a comment on UserVoice, but I thought it couldn't hurt discuss here.
This is configurable under the Settings tab.
- Lots of tech support happens from India. You are too expensive for this market. I would find it hard to sell your service as an addon to my app.
- Telecom is quite cheap out here. Figure out some alliances to bring down the cost (e.g. local SMS gateway, most of them use http api, but there are some SMTP based ones too).
- Additional SMS @ $0.15 translates to ~INR 7. SMS in my mobile phone plan would cost me ~10 times less. Not a correct comparison, but thats the language buyers use (enterprise buyers use it a lot) :)
- You are assuming direct consumers of your service. Think of indirect consumers too. Other startups who can piggyback on your offering to add value to their own product.
- Give an api where I can tell you the email message, sms message, various escalation options, option to repeat email/sms/phone after some delay if nobody responded. Also consider an SMTP api interface too. Not much of an effort for you if you already have the http api present.
- The api should also accept email addresses, mobile numbers and phone numbers. I might be signing up paying customers and using your app to send them alerts. I should be able to do this without having to register each of these email/phone numbers to you. Think of your pricing in this scenario.
- People mentioned ticketing system integration. Great idea. Extend it further. Also have an option where u will send the response back to the originating application.