If you are like most PagerDuty customers, you’re using PagerDuty to manage your on-call schedules and escalation processes to triage incidents coming from your monitoring tools.
However, in some cases, you may want someone from your team to manually page someone on-call. Or perhaps, you need a way for another team (not in PagerDuty) to page the on-call tech for a critical issue.
If that’s the case, we recommend checking out some of the below suggestions to make it easier for teams and other users to trigger incidents and notify the tech on-call.
Send an email from your inbox to trigger an incident
The easiest way to trigger an incident (without logging in or being a user in PagerDuty) is by sending an email.
If you have an email integration set up on your account, you can have people within your organization (or even your customers) send an email to one of your integration’s email addresses. This will then trigger an incident in PagerDuty and notify who is on-call.
Here are some ideas for managing these email addresses:
Post the relevant email address on an internal wiki page.
Especially if you have a lot of different services that are meant to notify different teams (i.e. a service for the System Administration team and another service for the Applications team), it may be difficult for team members to remember which email address to contact when they need to get in touch with an on-call tech. Post your PagerDuty email integration addresses on an internal wiki page to share which address should be contacted for which relevant issues.
Add your PagerDuty email addresses to an alias.
If you have an alias that team members prefer to each (i.e. ‘firstname.lastname@example.org’), you might want to add your PagerDuty email integration address to that alias so that team members have one less email address to remember when they are trying to contact whoever is on-call.
Set up email filters so that emails sent to one address trigger incidents for the appropriate team.
You can have multiple email integrations with the same email integration address. For example, you can have 2 email integrations that both have
email@example.com their email integration address. Of course, if you send an email to that address, 2 incidents would be triggered (one for each of those services that have that email integration address). However, you can set up filters on each of your emails so that an incident will only trigger on a service if the email matches certain rules. For example, for one service, you can set up an email rule that indicates incidents will only trigger if the body contains “devops team”. On the other service, you can set up an email rule that indicates incidents will only trigger if the body contains “sysadmin team”. If an email is sent to
firstname.lastname@example.org it matches either of those rules, then an incident will trigger on the appropriate service and notify the on-call tech for that service.
Note: As of December 6, 2016, you can have up to 25 duplicate email addresses across your services.**
Click a button on an internal wiki page to trigger an incident
Using our Events API, you can trigger an incident by sending PagerDuty an HTTP API call.
If you would like team members to be able to trigger incidents outside of PagerDuty, you can host an embeddable button on your internal wiki page that, when clicked, triggers an incident in PagerDuty via our Events API.
The PDJS library makes the implementation simple so that you don’t have to write any code or use server-side scripts.
Click a button in PagerDuty to trigger an incident
You can manually trigger incidents in PagerDuty with the push of a button. Of course, this would be ideal if a team member has login access to PagerDuty.
See Option 1 on How to Trigger an Incident to learn how to manually trigger incidents in PagerDuty.
Connect your ticketing system to PagerDuty
You can also connect your ticketing system to PagerDuty so that if a ticket, case, incident, or issue meets certain criteria, an incident will trigger in PagerDuty.
Check out some of our integration guides with our ticketing integration partners:
Trigger an incident programmatically
Our customers have created some easy to use tools that allow users to trigger incidents programmatically.
Here are some links that you can reference:
- resque-pagerduty: A Resque failure backend for triggering Pagerduty incidents
- PagerDuty event gem: A Ruby library for triggering and resolving incidents
- PagerDuty Incidents for Java: Java utility for programmatically triggering and resolving PagerDuty incidents
- PagerDutyBundle: Trigger PagerDuty events easily from your Symfony2 application
- pd-trigger: A lightweight, portable, and robust command line PagerDuty trigger utility