Incidents can come to PagerDuty in many different ways. Often times, events are automatically sent to PagerDuty via the Events API when certain thresholds are met in your monitoring tools. However, there may be some instances when a user needs to manually trigger an incident, or perhaps you need a way for other teams (outside PagerDuty) to page the on-call responder for a critical issue.

Check out the below suggestions to make it easier for teams to trigger incidents and notify on-call responders.

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 1 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 many 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 issues.
   
• Add your PagerDuty email addresses to an alias.
  If you have an alias that team members prefer to use (i.e. ‘urgent@company.com’), 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 notify@subdomain.pagerduty.com as 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 notify@subdomain.pagerduty.com and it matches either of those rules, then an incident will trigger on the appropriate service and notify the on-call tech for that service.
   
• 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. 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. Instructions here: Manually Trigger an Incident 1
   
• 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:
  
  Atlassian JIRA
  Kayako
  ServiceNow
  Zendesk
  Trigger an incident programmatically