New APIs Available Now

Have you ever said to yourself: “PagerDuty is great, but I wish I could better integrate it into the custom tools I already use.” Or maybe: “Why can’t I see more reports on the number of incidents each of my team members have worked on, bucketed by MTTR, split out by seniority of the person resolving the incident, graphed against the average length of their facial hair, etc, etc?”

Well, now you can! PagerDuty is happy to announce the release of a couple new REST APIs for querying your current and past incidents, as well as your various on-call schedules.

The new Incidents API allows you to query your incident data and integrate it into your custom operations dashboards. It also allows you to produce tailor-made summaries and incident reports for your ops teams on a weekly or monthly basis, or whatever time frame you like.

The new on-call Schedule API allows you to programmatically query on-call scheduling data. Using this API, you can integrate your on-call schedules with your existing calendar applications, user directories, and messaging systems such as Campfire, Hipchat or IRC. We hope that this API will help you bring better visibility into who is on-call in your organization, which can’t hurt in terms of ensuring that no problems or alerts go unattended even for short periods of time.

These two new APIs are currently read-only, but we hope to eventually broaden them so that you’ll be able to, say, create and edit your schedules via the same API. We also hope to eventually surface other REST resources (like user profiles, escalation policies, etc), via other APIs in the future as well.

For more information on our new REST APIs, or our existing monitoring integration API, please see our documentation.

Share on FacebookTweet about this on TwitterGoogle+
This entry was posted in Announcements, Features and tagged , . Bookmark the permalink.
  • Marc Hedlund

    Awesome, glad to hear it. Thanks for doing this.

    I’ll update my PagerDuty project  – https://github.com/precipice/pagerduty-tools — to use them.

  • http://michaelahale.com/ mikehale

    Nice job PD. Your service keeps getting better and better. I was thoroughly impressed that you stayed rock-solid during the EBS skynet outage.

  • http://twitter.com/kartar James Turnbull

    Nifty!  Well done.

  • http://www.soundbite.com Neil Silverman

     Do you guys have any intention on building a GUI front-end for these, particularly for the Incidents API?  I just want to know if that’s on your roadmap before I start building one myself…

    • John Laban

      Can you give us some details on what you mean by a GUI front-end for the incidents API?

      Our incidents page in PagerDuty surfaces much of the same information that the API surfaces.

      Or do you mean a GUI that can be used to tinker around with the API to help build requests before actually writing something that uses the API?

      • http://www.soundbite.com Neil Silverman

         Um… please don’t take this as a knock, because I really like your service, but your Incidents page is really only useful for looking at currently open/active incidents.  It’s not much use in reporting on resolved incidents.  I’d like to be able to slice and dice the data – for example, show me all incidents, including times to resolution, opened between and from service Z, grouped by assignee.  In other words, I want a genuine report builder.  The incidents page has very little searchability or data filtering capabilities – sure I can look at Resolved issues ordered by open time, but we have over 100K resolved incidents, that I can’t filter in any meaningful way.  I can’t choose to just look at last month, or last week.  I can’t choose to just look at one of the dozen services we have set up.  I can’t look at issues resolved by a particular employee.  With your API, one can pass in “search parameters”, and get back useful data sets, thus allowing much more useful and targeted reports to be generated.  This is definitely something we would like.  I’m a good enough Perl programmer that I can certainly do it myself, but it’s a not-insignificant work effort on an already busy schedule, so I didn’t want to start without double-checking whether or not you already have plans on your roadmap to introduce a report builder / beef up the incidents page with search/filter capabilities.  If you do, I’ll just wait.

        • John Laban

          Hi Neil,

          You bring up a lot of good points.  We could definitely use more generic reporting functionality in PagerDuty, and it’s on our roadmap, but probably won’t be tackled in the short term (i.e. 2011).  We didn’t want to block our users though, so it’s one of the reasons we opened up the API for you guys.

          That being said, you can already do *one* of your (many) above wishes, so I figured I’d point that out, as a meager peace offering:

          > I can’t choose to just look at one of the dozen services we have set up.

          If you click on the service in question in the Services tab, you should be see only the incidents that have been opened against that service in the past.  It’s pre-filtered, but in other respects the incident view there is the same.