How to send Digital Empire alerts to PagerDuty

If a broken Meta Pixel or a missed CPSC eFiling is a page-worthy incident for your team, PagerDuty is where the alert should go. Digital Empire posts to the PagerDuty Events API v2 documented at developer.pagerduty.com -- the current-generation event ingestion API that supports deduplication, alert grouping, and rich payload context.

The 3-step Events API v2 setup

Events API v2 uses a per-service integration key. You create the service in PagerDuty, generate an integration key, and hand that key to us.

In PagerDuty, go to Configuration -> Services and click "New Service." Pick "Use our API directly," choose "Events API v2," name the service (for example "Digital Empire Portfolio Alerts"), and assign an escalation policy. Click "Add Service."
On the service's Integrations tab, copy the "Integration Key" -- a 32-character opaque string. This is your routing_key.
On the Digital Empire integrations page for your product (PixelProof, EntryProof, or TariffWatch), pick "PagerDuty" as the channel type. Paste https://events.pagerduty.com/v2/enqueue?routing_key=YOUR_KEY_HERE (with your key substituted) as the Webhook URL. Save. Our dispatcher extracts the routing_key query parameter, moves it into the request body, and POSTs the payload PagerDuty expects.

Screenshot placeholder -- PagerDuty service Integrations tab with the Events API v2 integration key. Andy will upload the real screenshot after wire-up.

What we actually send to PagerDuty

The Events API v2 request body is documented at developer.pagerduty.com under "Send an Event". Our dispatcher formats each alert as a valid trigger event:

{ "routing_key": "YOUR_INTEGRATION_KEY", "event_action": "trigger", "dedup_key": "pixel_missing:your-store.myshopify.com", "payload": { "summary": "Pixel break on your-store.myshopify.com", "source": "your-store.myshopify.com", "severity": "critical", "component": "pixel_missing", "custom_details": { "message": "The Meta Pixel is no longer firing PageView on your product pages.", "fields": {} } }, "links": [{ "href": "https://digital-empire-app.vercel.app/meta-monitor", "text": "Open dashboard" }] }

Two things to notice:

Severity mapping. Our internal ladder (critical, high, medium, low) maps to PagerDuty's four levels: critical to critical, high to error, medium to warning, low to info. This matches the Common Event Format described on developer.pagerduty.com. PagerDuty renders each in incident-list color coding accordingly.
Deduplication key. We build dedup_key as {event_type}:{subject_key} -- so a pixel_missing event for the same store hitting our dispatcher three times in an hour will collapse into a single PagerDuty incident. That is important: without it, every alert would spawn a new incident and page whoever is on call every time.

Escalation policy -- how alerts route to your team

The escalation policy you assigned when creating the service is where PagerDuty's real value lives. When Digital Empire sends a trigger event, PagerDuty matches the routing_key to the service, walks the escalation policy, and pages the current on-call responder via whatever channels (SMS, phone, push, email) they configured. The escalation policy documentation on PagerDuty's site at support.pagerduty.com covers the standard policy shape.

If you want different alerts to page different teams, create one PagerDuty service per team, generate one integration key per service, and add one Digital Empire webhook row per service on the integrations page (each with a different event filter).

Deduplication, resolution, and re-triggering

PagerDuty holds an incident open until it receives a resolve event with the same dedup_key. Right now our dispatcher only sends trigger events -- we do not auto-resolve. When you fix the underlying issue (the Meta Pixel starts firing again, the eFiling batch is uploaded, the tariff exposure closes), you or your team member should manually resolve the incident in the PagerDuty console. Auto-resolve on subsequent healthy scans is on the roadmap for the PixelProof product at /meta-monitor/roadmap.

Our dispatcher treats the HTTP status codes returned by PagerDuty per RFC 9110 at rfc-editor.org -- 2xx is success, 429 halts retry, 5xx triggers one retry, 4xx marks permanent rejection.

If a trigger event fires with a dedup_key that matches an already-open incident, PagerDuty appends the payload to the existing incident and does not page again. This is the mechanism that keeps a persistent problem from paging your on-call every 15 minutes.

Runbook Automation and severity filtering

If you use PagerDuty Runbook Automation (formerly Rundeck) for automated remediation, you can wire our alerts into it via the standard PagerDuty webhook subscription -- the Runbook Automation docs on runbook.pagerduty.com describe how to bind a workflow to an incoming incident from a specific service.

On the Digital Empire integrations page, we recommend setting the severity floor to high or critical for PagerDuty specifically. Pages should be reserved for things that need human attention now; medium and low findings are better routed to Slack or a generic webhook for asynchronous review.

Was this helpful?

Yes / No

FAQ

Do I need a PagerDuty Business or Digital Operations plan? Any PagerDuty plan that includes the Events API v2 will work. As of Aug 2026 that includes every current tier -- verify current on pagerduty.com/pricing.

Can I auto-resolve incidents when the problem goes away? Not yet -- see the roadmap note above. Manual resolution is required today.

What happens if PagerDuty is down? Our dispatcher retries once on 5xx or timeout, then marks the webhook failed. When PagerDuty recovers, subsequent events fire normally -- but events during the outage are lost. If PagerDuty is your only alert destination, we strongly recommend adding a Slack or generic webhook as a secondary destination on the same integrations page.

How do I test the wire without paging anyone? Set the escalation policy on the service to a schedule that has nobody on call, or temporarily switch it to a policy with a "delay before notify" of 24 hours. Send the test alert, verify it lands, then restore the policy.

Still stuck? Email hello@citationsafe.com or hello@argushq.ai.