Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

Plugin Information

View PagerDuty on the plugin site for more information.

Allows users to trigger postbuild incidents via PagerDuty


  • Trigger incidents on various job statuses Success/Failure/Aborted/Unstable/Not_Built
  • Trigger incidents based on number of consecutive build results
  • Automatically Resolve incidents when job is back to normal
  • Pipeline compatible
  • TokenMacro consumer (TokenMacro - adds reusable macro expansion capability)

pipeline example:

if resolve == false, the pagerduty triggers an incident and returns the incidentKey

pagerduty(resolve: false, serviceKey: "$SERVICE_KEY", incidentKey: "$INCIDENT_KEY", incDescription: "pipeline test incident", incDetail: "pipeline test")



Version History

Version 0.4.1 (Mar 12, 2019)

  • Add TokenMacro support
  • Bug fixes
  • Code refactor

Version 0.3.0 (Jan 31, 2017)

  • Pipeline compatible
  • Code refactor

Version 0.2.6 (June 20, 2017)

  • Bug fixes
  • PagerDuty v2 compatibility (migrating from square PD utility to dikhan's PD client)

Version 0.2.5 (March 10, 2017)

  • Bug fixes

Version 0.2.4 (March 30, 2016)

  • Allow automatic resolution of the incident on BACK-TO-NORMAL (from not success to success)

Version 0.2.3 (March 09, 2016)

  • Bug fixes

Version 0.2.2 (January 03, 2016)

  • Allow triggering alert in all job statuses (SUCCESS/FAILED/ABORTED/UNSTABLE/NOT_BUILT)
  • Allow using multiple service keys for different job

Version 0.2.1 (December 08, 2015)

  • Allow using Environment Variables for config

Version 0.2.0 (September 26, 2015)

  • Initial public release


  1. Unknown User (brightball)

    Will alerting on Success or Back to Normal resolve an open page? I was considering pairing this with the site monitor plugin and sometimes sites will become non-responsive but then come back up. In those cases, it's really helpful for whatever is doing the checking to be able to close the page out.

    1. Unknown User (alexanderlz)

      It's in my nearest-future plans.

  2. Unknown User (grayaii)

    Any chance of enhancing the plugin to include a client link and a custom data payload?

    Like so:

    1. Unknown User (grayaii)

      I created a PR for adding details myself, here: https://github.com/jenkinsci/pagerduty-plugin/pull/3

      It's been working fine for me.  If you can merge that bad boy in (or comment on any issues you see with the code, let me know, I'll try to fix it up ASAP) :)

  3. Unknown User (flands)

    Any chance of being able to specify the user to assign the incident to? Assuming you have environment variables, it would be nice to assign incidents to the people performing the Jenkins operation

    1. Unknown User (grayaii)

      I'm pretty sure this plugin is using escalation policies, not assignees: https://v2.developer.pagerduty.com/docs/incident-creation-api#making-a-request The workaround would be to create various escalation policies in pager duty and then pass in the Service Integration Key as a variable.

      1. Unknown User (flands)

        Ah, yeah that would be a deal breaker for me as it does not scale. All code pushers are in PD so looking for dynamic way to assign issues when their code push doesn't work. Thanks for the info!

  4. Unknown User (hemantnarang)

    We are trying to use the pagerduty plugin on our Jenkins Slave server.

    As a post build action, we have an email notification first and then the pagerduty incident trigger. The email trigger happens but the pagerduty doesn't.

    Any thoughts?