Guides · PagerDuty

Get a Mac notification for PagerDuty incidents

PagerDuty can post a webhook the moment an incident triggers, is acknowledged or resolves. Point one at EventBar and each incident pops up in your menu bar, with this week's incident count a glance away, even when the PagerDuty app is closed or your phone is in another room.

Needs: the free EventBar app on your Mac, an EventBar account, and a PagerDuty account where you are a Manager, Admin or Account Owner (or a team Manager, for that team's services). About five minutes. PagerDuty preset, signature verified.

Steps

Create the webhook URL. In the EventBar dashboard, open the Webhooks tab, pick the group this belongs to (one group per site or app is the usual shape), choose the provider PagerDuty, name it, and press Create. Copy the URL; it stays visible and can be rotated any time.
Paste it into PagerDuty. In PagerDuty: Integrations, then Generic Webhooks (v3), then New Webhook. Paste the URL into Webhook URL, choose the scope (an account, a team or a single service), and under Event Subscription tick events such as incident.triggered, incident.acknowledged and incident.resolved, then press Add Webhook. PagerDuty shows the signing secret once, in the dialog that follows: copy it before you close the dialog and paste it into the hook card in EventBar. For one service only, the same form is on the service's Integrations tab under Webhooks.
Trigger one. Most services offer a test delivery; otherwise do the real thing once. It shows up in the dashboard's Events tab within a second and in the menu bar, as an undefined type named after the event. That first one is your proof the wiring works.
Make it read well. Press Define on the new type and give it a title and a body template. Fields come from the payload, nested ones with dots. The table below is a starting point.

This preset is on Plus and Pro. Free can do the same with a Generic JSON hook and a type field of event.event_type, without the signature check.

What you'll see

Type	Title	Body template
`incident.triggered`	New incident	`#{event.data.number} {event.data.title} · {event.data.service.summary} · {event.data.urgency}`
`incident.acknowledged`	Acknowledged	`{event.agent.summary} on #{event.data.number} {event.data.title}`
`incident.resolved`	Resolved	`#{event.data.number} {event.data.title} · {event.data.service.summary}`
`incident.annotated`	New note	`{event.agent.summary}: {event.data.content}`

Every type has its own switch in the menu bar, so a noisy one can be quiet on this Mac and still counted. Counts cover the last hour, 24 hours, 7 days, 30 days and all time.

Worth knowing

The type is the event's event.event_type, so incident.triggered and incident.resolved each get their own switch and count. Leave incident.triggered loud and mute the rest from the menu bar if you only want to hear about new incidents.
The signature is X-PagerDuty-Signature: v1=…, a hex HMAC-SHA256 of the raw body keyed with the webhook's signing secret. While a secret is being rotated PagerDuty sends one v1= per secret, comma separated, and EventBar accepts the delivery if any of them matches. PagerDuty signs no timestamp, so there is no clock window to worry about.
Duplicates are dropped by the X-Webhook-Id header, which PagerDuty repeats on every delivery attempt of the same webhook, so its retries (for up to 48 hours) never count twice. Without that header the event id is used instead.
{event.agent.summary} is the person who acted; it is empty when an automation or an integration did it. {event.data.html_url} links to the incident if you want it in the text.
The webhook's Test tab sends a pagey.ping event, signed like any other, which arrives as its own type: a quick proof the URL and the secret are right before a real incident does it.

The full contract, including how each preset reads a payload and what the answers mean, is in the API docs. Something about PagerDuty's payload changed? Tell us and we'll fix the guide.