Hi @Cam, @mkoch,
You have a couple of options here - we use both:
Add-Ons and configure the URL you want to display inline, along with the Service you want to bind it to. Note that you may be stymied by Cross-Site-Scripting protections if you’re using external sites, or Atlassian Confluence, etc. as this loads in an iFrame.
- Send a document url along with the alert (e.g. use the Nagios
SERVICENOTESURL field, a custom field in Sensu, or a new
link if you’re working with the API directly). This won’t unfurl inline, but gets past any CSRF limitations (as you’re opening a separate link in a new tab/window.
If your PagerDuty Services are focussed enough, using the Add-Ons should work beautifully as you can configure your targeted documentation and graphs with every Incident.
What you cannot do, is send a random url in the alert body and have it unfurled inline. Because a lot of our PagerDuty Service implementations are not specific (i.e. we may take 5000 different types of services + hosts in one Service), we can either include a documentation index and a generic set of graphs, or nothing at all, relying on the documentation / graph link to be included in the body of the alert (which we do, so it works for us for now).